1 2017-12-06 00:35:12 <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 ?
 2 2017-12-06 00:36:24 <gevs> HO
 3 2017-12-06 00:36:37 <gevs> the one im reproducing is the wrong input :D i must be on the right way !!!!
 4 2017-12-06 00:37:40 <gevs> so the transaction im producing : https://pastebin.com/ujKDPafR
 5 2017-12-06 00:38:51 <gevs> now this second input it gives me "f86186" which is actually the redeem script for input with n 0 in the second input
 6 2017-12-06 00:39:01 <gevs> sorting this - i might have a little index problem and be very near to the right thing :P
 7 2017-12-06 01:31:43 <gevs> guys i think this is most learn-full debugging ever xD
 8 2017-12-06 01:31:48 <gevs> so the input i decide to spend
 9 2017-12-06 01:31:54 <gevs> turns out it is a change address xD
10 2017-12-06 01:32:04 <gevs> so the derivation for that one is different xpub/1/0 :P
11 2017-12-06 01:32:09 <gevs> #comeon
12 2017-12-06 01:32:35 <gevs> oh my god i got both hashes :D together :)
13 2017-12-06 01:33:00 <gevs> meh :( Error: 64: scriptsig-not-pushonly    arubi if this is in your timezone :P
14 2017-12-06 01:33:07 <gevs> damn it i got both hashes fine
15 2017-12-06 01:33:38 <gevs> ha when i paste the payload in coin.bin its telling me one of my inputs isnt signed.
16 2017-12-06 01:38:49 <gevs> ok got the right payload, come on let it broadcast :O
17 2017-12-06 01:39:01 <gevs> )
18 2017-12-06 01:39:01 <gevs> array (
19 2017-12-06 01:39:01 <gevs> SUCCESS!
20 2017-12-06 01:39:01 <gevs> 'success' => true,
21 2017-12-06 01:39:01 <gevs> 'txid' => '09d01daebfb08d9124ba442d8db5e9e11f9cdd29e799d471f7c37768148a4e9a',
22 2017-12-06 01:39:04 <gevs> :D :D :D :D :D :D <3
23 2017-12-06 01:39:55 <gevs> this is really happening
24 2017-12-06 01:40:04 <gevs> my transaction got through <3
25 2017-12-06 01:41:21 <gevs> now let that thing confirm hahahah :D this is amazing
26 2017-12-06 01:49:28 <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 :)
27 2017-12-06 01:50:15 <gevs> oh damn the bitcoin deposit appears on bittrex
28 2017-12-06 01:50:27 <gevs> as pending, but the tether not
29 2017-12-06 01:50:59 <gevs> ha
30 2017-12-06 01:51:05 <gevs> but omniwallet.org says the tether is there :)
31 2017-12-06 01:51:10 <gevs> this is awesome :D
32 2017-12-06 01:52:21 <gevs> and i got a confirm :)
33 2017-12-06 01:53:30 <gevs> https://www.omniwallet.org/explorer/inspector?view=09d01daebfb08d9124ba442d8db5e9e11f9cdd29e799d471f7c37768148a4e9a
34 2017-12-06 01:53:35 <gevs> "to_address" all fine :)
35 2017-12-06 01:55:02 <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 :)
36 2017-12-06 01:55:12 <gevs> amazing help here !! thanks lots!
37 2017-12-06 02:02:04 <gevs> haha bittrex recognizes them :D
38 2017-12-06 02:02:13 <gevs> so happy right now :)
39 2017-12-06 02:03:01 <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 :)
40 2017-12-06 07:11:01 <arubi> sweet :)  yw gevs
41 2017-12-06 17:18:28 <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?
42 2017-12-06 17:19:30 <arubi> transferred?  what does that mean?
43 2017-12-06 17:20:52 <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.
44 2017-12-06 17:21:44 <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
45 2017-12-06 17:22:11 <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
46 2017-12-06 17:23:38 <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?
47 2017-12-06 17:24:15 <arubi> why would they care for block B?  A is good enough for those who heard about it first
48 2017-12-06 17:24:45 <Sentineo> it is really when 1-2-3-A-C or 1-2-3-B-C comes in that breaks the tie
49 2017-12-06 17:24:48 <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
50 2017-12-06 17:24:53 <ponzibanker> arubi: I’m just wondering how core handles it…I don’t think it ignores it…right?
51 2017-12-06 17:25:57 <arubi> it's probably not completely ignored, but the state of the utxo it produces is
52 2017-12-06 17:28:29 <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 :)
53 2017-12-06 17:28:48 <arubi> after, for sure
54 2017-12-06 17:29:06 <arubi> transactions in B which aren't in A are valid for the A chain
55 2017-12-06 17:29:43 <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
56 2017-12-06 17:30:56 <ponzibanker> groking :) …
57 2017-12-06 17:31:17 <Sentineo> when you receive a block you validate all txes in it again
58 2017-12-06 17:31:26 <Sentineo> you can see it in zeromq
59 2017-12-06 17:31:32 <Sentineo> you get all of them again
60 2017-12-06 17:31:46 <Sentineo> so during that validation  you find out which one is ok which one is not
61 2017-12-06 17:34:31 <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)?
62 2017-12-06 17:35:09 <arubi> right
63 2017-12-06 17:35:13 <Sentineo> ok lets say node that has 1-2-3-B receives 1-2-3-A-C as the next block
64 2017-12-06 17:36:04 <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)
65 2017-12-06 17:36:08 <arubi> transactions from B go into mempool, and A-C are replayed on top of 3.  transactions from A-C are removed from mempool
66 2017-12-06 17:37:00 <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
67 2017-12-06 17:37:12 <Sentineo> right, in practice most of transaction that were in A were in B also
68 2017-12-06 17:41:33 <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
69 2017-12-06 17:41:33 <ponzibanker> then how does that get resolved? Apologies if I’m being confusing.
70 2017-12-06 17:43:22 <Sentineo> every TX has inputs and outputs
71 2017-12-06 17:43:33 <Sentineo> blocks are a time stamp
72 2017-12-06 17:44:14 <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
73 2017-12-06 17:44:35 <Sentineo> but do not forget that the rest of the network validated it before basically, so the odds of it happening are slim
74 2017-12-06 17:48:51 <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?
75 2017-12-06 17:49:31 <Sentineo> yes
76 2017-12-06 17:49:49 <Sentineo> of course, mempool has txes that are not in blocks and are unspent
77 2017-12-06 17:50:03 <Sentineo> so if it gets to the block that tx is spent
78 2017-12-06 17:50:12 <Sentineo> can not be in the mempool anymore
79 2017-12-06 17:51:07 <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?
80 2017-12-06 17:52:29 <Sentineo> yes
81 2017-12-06 17:53:41 <Sentineo> now if some are not in A nor in B they will get back to the mempool
82 2017-12-06 17:54:00 <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?
83 2017-12-06 17:54:31 <Sentineo> yes
84 2017-12-06 17:55:22 <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?
85 2017-12-06 17:56:02 <Sentineo> do not get your question
86 2017-12-06 17:56:12 <Sentineo> how can you remove a tx from the mempool that does not exist?
87 2017-12-06 17:59:11 <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)…
88 2017-12-06 18:05:48 <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.
89 2017-12-06 18:59:26 <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
90 2017-12-06 19:00:20 <fnb_theory> It has also been timing out when trying to download blocks from peers.
91 2017-12-06 19:28:43 <pipan> Hi there, I am new here, apologies for dummy questions
92 2017-12-06 19:29:15 <pipan> I have an ackward situation in my BTC node and 'd like some help/opinions if possible
93 2017-12-06 19:30:07 <pipan> I generate and address in my wallet, then I send some btc
94 2017-12-06 19:30:27 <pipan> I can see the transaction in my node and in blockchain
95 2017-12-06 19:30:35 <pipan> but my wallet balance is zero
96 2017-12-06 19:30:43 <pipan> any thoughts?
97 2017-12-06 20:21:34 <cluelessperson> pipan: this is better for #bitcoin
98 2017-12-06 20:21:44 <cluelessperson> You're not developing bitcoin software
99 2017-12-06 20:55:21 <pipan> cluelessperson: I am developing software that uses a BTC node