Transcript for #bitcoin-dev 2017/12/06

00:35 gevs ok im hurting something else. will the public keys automatically HAVE to be sorted lexicographically as they are for the first redeemscript we reproduced ?
00:36 gevs HO
00:36 gevs the one im reproducing is the wrong input :D i must be on the right way !!!!
00:37 gevs so the transaction im producing : https://pastebin.com/ujKDPafR
00:38 gevs now this second input it gives me "f86186" which is actually the redeem script for input with n 0 in the second input
00:39 gevs sorting this - i might have a little index problem and be very near to the right thing :P
01:31 gevs guys i think this is most learn-full debugging ever xD
01:31 gevs so the input i decide to spend
01:31 gevs turns out it is a change address xD
01:32 gevs so the derivation for that one is different xpub/1/0 :P
01:32 gevs #comeon
01:32 gevs oh my god i got both hashes :D together :)
01:33 gevs meh :( Error: 64: scriptsig-not-pushonly arubi if this is in your timezone :P
01:33 gevs damn it i got both hashes fine
01:33 gevs ha when i paste the payload in coin.bin its telling me one of my inputs isnt signed.
01:38 gevs ok got the right payload, come on let it broadcast :O
01:39 gevs SUCCESS!
01:39 gevs array (
01:39 gevs 'success' => true,
01:39 gevs 'txid' => '09d01daebfb08d9124ba442d8db5e9e11f9cdd29e799d471f7c37768148a4e9a',
01:39 gevs )
01:39 gevs :D :D :D :D :D :D <3
01:39 gevs this is really happening
01:40 gevs my transaction got through <3
01:41 gevs now let that thing confirm hahahah :D this is amazing
01:49 gevs waiting waiting for this confirm :D come on - 0.00106482 BTC fee should do - cant wait to see if bittrex allows to withdraw to them directly but i dont see why they wouldnt :)
01:50 gevs oh damn the bitcoin deposit appears on bittrex
01:50 gevs as pending, but the tether not
01:50 gevs ha
01:51 gevs but omniwallet.org says the tether is there :)
01:51 gevs this is awesome :D
01:52 gevs and i got a confirm :)
01:53 gevs https://www.omniwallet.org/explorer/inspector?view=09d01daebfb08d9124ba442d8db5e9e11f9cdd29e799d4...
01:53 gevs "to_address" all fine :)
01:55 gevs bittrex seems not to want to display my usdt though ... that might be that bittrex would use the old system to determine usdt owners.. or whatever i dont care, for the real deal i will send the funds to a omnicore wallet :)
01:55 gevs amazing help here !! thanks lots!
02:02 gevs haha bittrex recognizes them :D
02:02 gevs so happy right now :)
02:03 gevs anyone who wants to see code of this bugfix, i will be reorganizing my inputs in https://github.com/evias/blockchain-cli will be renamed to a little stand alone omni-copay-recovery tool (and probably non-omni multisig recovery if i get time to work on it a little :)
07:11 arubi sweet :) yw gevs
17:18 ponzibanker Do the transactions of a block (hereinafter block-A) that’s transferred to the secondary blockchain (during a temporary fork) get taken out of the mempool of that node?
17:19 arubi transferred? what does that mean?
17:20 ponzibanker arubi: I’m using terminology from Mastering Bitcoin…it’s the situation where two miners have won the block close to the same time and the network is split…some validating nodes beliving A won and some believing B won.
17:21 ponzibanker So the chain that thinks A won looks like 1-2-3-A and the side that thinks B won looks like 1-2-3-B
17:22 arubi so if a transaction was in a node's mempool and is now in a block, then it's not in mempool anymore. if that block gets re-orged, the state is replayed and transactions can return to mempool
17:23 ponzibanker arubi: k…so the transactions of block A are removed, but now that node gets the block from B, if the transactions are different does the node remove it’s transactions as well?
17:24 arubi why would they care for block B? A is good enough for those who heard about it first
17:24 Sentineo it is really when 1-2-3-A-C or 1-2-3-B-C comes in that breaks the tie
17:24 arubi if B's chain gets longer and A is re-orged, then eventually only transactions that did not get into the B->.. chain stay in mempool
17:24 ponzibanker arubi: I’m just wondering how core handles it…I don’t think it ignores it…right?
17:25 arubi it's probably not completely ignored, but the state of the utxo it produces is
17:28 ponzibanker arubi: interesting…so the second (valid) block is ignored by the node that has accepted the first (valid) block from the standpoint of the chainstate…but it would be interesting to know whether the mempool is updated before and after the reorg…I wish I knew C better :)
17:28 arubi after, for sure
17:29 arubi transactions in B which aren't in A are valid for the A chain
17:29 arubi transactions spending from utxos that only exist in the B chain are invalid in the A chain and so will not be in node's mempool
17:30 ponzibanker groking :) …
17:31 Sentineo when you receive a block you validate all txes in it again
17:31 Sentineo you can see it in zeromq
17:31 Sentineo you get all of them again
17:31 Sentineo so during that validation you find out which one is ok which one is not
17:34 ponzibanker Sentineo: So the first time the node gets winning block A it starts validating the block…and once it validates that block is the mempool affected at all (e.g. transactions in that block removed from the mempool)?
17:35 arubi right
17:35 Sentineo ok lets say node that has 1-2-3-B receives 1-2-3-A-C as the next block
17:36 Sentineo it will know A is new so will rechack all txes in A and of course will validate C. The result will be a new chainstate (utxo set)
17:36 arubi transactions from B go into mempool, and A-C are replayed on top of 3. transactions from A-C are removed from mempool
17:37 Sentineo most often if they hear about A before, they keep it in case it needs to be revalidated, and the way how to revert the chainstate to state before that block is recorded
17:37 Sentineo right, in practice most of transaction that were in A were in B also
17:41 ponzibanker Sentineo: Does the order matter here? So when the node gets the next block in your example (1-2-3-A-C) and validates A and C, at the time of that validation it tries to remove transactions from the mempool and if there’s any overlap with B (that’s already been removed) it just moves on and doesn’t cause an error invalidation? And then when transactions from B go back into the mempool, if there’s overlap with A and C
17:41 ponzibanker then how does that get resolved? Apologies if I’m being confusing.
17:43 Sentineo every TX has inputs and outputs
17:43 Sentineo blocks are a time stamp
17:44 Sentineo so first block A is processed and if it has valid txes block C is processed. In case there is a tx in C which is not valid (e.g. trying to spend and input that is already spent) it would be dropped
17:44 Sentineo but do not forget that the rest of the network validated it before basically, so the odds of it happening are slim
17:48 ponzibanker Sentineo: Is the mempool altered after a node validates each block. That is, the node determines that all of the transactions in the block are valid + the other validation stuff and then removes all of the transactions that are in that block from the mempool?
17:49 Sentineo yes
17:49 Sentineo of course, mempool has txes that are not in blocks and are unspent
17:50 Sentineo so if it gets to the block that tx is spent
17:50 Sentineo can not be in the mempool anymore
17:51 ponzibanker Sentineo: that makes sense…so the earlier example, the node that processed 1-2-3-B has removed some tx from the mempool after it validated it right?
17:52 Sentineo yes
17:53 Sentineo now if some are not in A nor in B they will get back to the mempool
17:54 ponzibanker And so that same node gets 1-2-3-A-C and it processes A first and there’s some overlap between A and B so some tx in A have already been removed previously from B…right?
17:54 Sentineo yes
17:55 ponzibanker Sentineo: k..that clears up my first issue…that core doesn’t care if when removing a tx from the mempool it doesn’t exist…right?
17:56 Sentineo do not get your question
17:56 Sentineo how can you remove a tx from the mempool that does not exist?
17:59 ponzibanker Sentineo: 1-2-3-B has transactions that are in 1-2-3-A in the earlier example, B is validated first so there’s an attempt to remove all transactions in B from the mempool…now A is validated and it has tx that were previously removed from the mempool during B’s validation….during A’s validation the node is trying to remove a tx that is no longer in mempool (I realize I must be missing something here)…
18:05 ponzibanker Sentineo: and my reference to the earlier example was between 1-2-3-B and 1-2-3-A-C…I just left off the C validation to make it simpler.
18:59 fnb_theory Hey guys, not sure if this is the right channel, but my 0.15.1 node has been lagging (block height) behind for the last 24 hours. What could be the cause of that? I have enough disk space, RAM etc
19:00 fnb_theory It has also been timing out when trying to download blocks from peers.
19:28 pipan Hi there, I am new here, apologies for dummy questions
19:29 pipan I have an ackward situation in my BTC node and 'd like some help/opinions if possible
19:30 pipan I generate and address in my wallet, then I send some btc
19:30 pipan I can see the transaction in my node and in blockchain
19:30 pipan but my wallet balance is zero
19:30 pipan any thoughts?
20:21 cluelessperson pipan: this is better for #bitcoin
20:21 cluelessperson You're not developing bitcoin software
20:55 pipan cluelessperson: I am developing software that uses a BTC node