Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    BeamTalk
    @BeamTalk
    p (Ch: @beamdevsupport)
    thanks!
    vsnation
    @vsnation1_twitter
    hi
    energyburn
    @energyburn
    :wave:
    BeamTalk
    @BeamTalk
    p (Ch: @beamdevsupport)
    yeah i think 12h is the default (if you can change that at all)
    Hannibal Rekter(Ch: @beamdevsupport)
    it is set at 12h but can be changed in the code as far as I remember
    Hannibal Rekter(Ch: @beamdevsupport)
    that mean, it is not changeable by users
    p (Ch: @beamdevsupport)
    ah ok
    p (Ch: @beamdevsupport)
    so when i look at the kernelid of the utxo (in the receiving mobile beam-wallet), it cant be found on the explorer
    p (Ch: @beamdevsupport)
    can it be that it was part of an orphan block maybe?
    p (Ch: @beamdevsupport)
    ah right
    p (Ch: @beamdevsupport)
    ok i think the problem is my mobile wallet
    p (Ch: @beamdevsupport)
    it says blockchainheight 342041 and the actuall current height is 368550 on testnet 😱
    BeamTalk
    @BeamTalk
    p (Ch: @beamdevsupport)
    ah nvm lol its fine was on mainnet
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    this is ok)
    Anatol (Ch: @beamdevsupport)
    this means that transaction has not completed successfully, and selected coins have been unlocked
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    can you describe the scenario and environment for reproducing this?
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    ok, thank you! I will try to reproduce this. It seems like the answer from the receiver was lost for some reason, but the sender should stop waiting for the receiver after 12h (720 blocks)
    p (Ch: @beamdevsupport)
    and now i have the state and everything intact if you want me to do anything with it
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    If you cannot cancel transactions this means that sender created tranasction and pushed it to the node. Do you have log record "Transaction created. Kernel"? There should be 'max height' value if it is greater than blockchain height - everything is ok)
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    it seems that on testnet we have very low block rate
    p (Ch: @beamdevsupport)
    mhm
    p (Ch: @beamdevsupport)
    ill put some hashrate on it
    p (Ch: @beamdevsupport)
    but still, this tx will stay in sending?
    p (Ch: @beamdevsupport)
    ok i understand now i think, :)
    p (Ch: @beamdevsupport)
    it was on sending for such a long time because the max-height was not reached
    p (Ch: @beamdevsupport)
    i was able to cancel it now
    Anatol (Ch: @beamdevsupport)
    right
    Anatol (Ch: @beamdevsupport)
    the logic is the following:
    • sender and receiver negotiate about tx (sign it)
    • sender sends tx to the node
      from this moment sender make decisions only on kernel proofs which he gets every new tip, until it reaches max height (node will not accept tx with max height lower than its tip)
    BeamTalk
    @BeamTalk
    p (Ch: @beamdevsupport)
    so for that time, the utxos are locked?
    p (Ch: @beamdevsupport)
    what i was trying to do is that i cancel the tx if it takes too much time, in order to unlock the utxos
    Anatol (Ch: @beamdevsupport)
    yes, because there is a possibility that transaction will go to the blockchain, if you unlock them before the max height, then you will be able to select them for newer tranasction, but this new transaction will be failed since these utxos are spent
    p (Ch: @beamdevsupport)
    i see, thank you for explaining
    BeamTalk
    @BeamTalk
    p (Ch: @beamdevsupport)
    can I assume that such a scenario is not happening often on the mainnet? I do not completely understand why the the transaction did not go through.
    p (Ch: @beamdevsupport)
    not often = <1% of all tx
    p (Ch: @beamdevsupport)
    i guess this problem is related to the low rate of blocks
    BeamTalk
    @BeamTalk
    Anatol (Ch: @beamdevsupport)
    low block rate influences on the timeouts (internally they are set in blocks)
    @vlad_gelfer can tell you about the reasons why node can reject transaction and about probabilities not to go through)
    p (Ch: @beamdevsupport)
    kk, thank you much appreciated (i feel like asking really basic questions :p)
    Anatol (Ch: @beamdevsupport)
    np)
    BeamTalk
    @BeamTalk
    Vladislav G(Ch: @beamdevsupport)
    Node would reject transaction if it's (1) invalid, (2) references inputs that are already spent, i.e. double-spend attempt, (3) not valid for the current blockchain height according to the min/max height in the tx kernel, i.e. timed-out, (4) has fee below the required minimum, which is ~100 groth by now.
    BeamTalk
    @BeamTalk
    Jimmy (Ch: @beamdevsupport)
    is there any interface to retrieve the transactions and utxos through a http api?
    Jimmy (Ch: @beamdevsupport)
    is there any interface to retrieve the transactions and utxos through a http api?
    Jimmy (Ch: @beamdevsupport)
    is there any interface to retrieve the transactions and utxos through a http api?
    BeamTalk
    @BeamTalk
    Jimmy (Ch: @beamdevsupport)
    great
    Jimmy (Ch: @beamdevsupport)
    thanks
    Jimmy (Ch: @beamdevsupport)
    love u😜
    BeamTalk
    @BeamTalk
    Lil β‚Ώit(Ch: @beamdevsupport)
    Beam and Bitcoin πŸ…
    vsnation
    @vsnation1_twitter
    Hi all
    Guy Corem
    @vcorem
    They released the article awhile back and did some corrections.