1 2018-03-24 04:22:41	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #12412: Enable spectre mitigations when supported by compiler. (06master...06spectre-mitigation) 02https://github.com/bitcoin/bitcoin/pull/12412
 2 2018-03-24 04:53:38	0|midnightmagic|Uh
 3 2018-03-24 04:54:01	0|midnightmagic|Who was it who built a new block parser? I know of znort's but there was a new one I saw very recently ..  was it achow101 ?
 4 2018-03-24 04:54:18	0|achow101|block parser?
 5 2018-03-24 04:54:35	0|midnightmagic|yea, a raw interface to dump the contents of on-disk block .dat files.
 6 2018-03-24 04:54:40	0|achow101|I have one that I use personally, it shouldn't be public
 7 2018-03-24 04:54:49	0|midnightmagic|oh.
 8 2018-03-24 04:55:11	0|midnightmagic|In that case, there was one I saw on github-- and I'm presuming it wasn't you, then. :)
 9 2018-03-24 04:55:54	0|achow101|I recently put it on github and may have accidentally not made it a private repo
10 2018-03-24 04:56:55	0|achow101|midnightmagic: maybe you're thinking of https://github.com/alecalve/python-bitcoin-blockchain-parser
11 2018-03-24 04:57:12	0|achow101|or blocksci?
12 2018-03-24 04:57:25	0|midnightmagic|I believe it was written in C++ or C.
13 2018-03-24 04:57:38	0|midnightmagic|-- which is why I was so happy with it, since I'd been relying on znort's for a long time.
14 2018-03-24 04:58:05	0|achow101|https://github.com/citp/BlockSci
15 2018-03-24 05:03:06	0|midnightmagic|hrmm..  doesn't look familiar.
16 2018-03-24 05:03:10	0|midnightmagic|thanks though!
17 2018-03-24 05:08:02	0|midnightmagic|achow101: I think I may have been misremembering this: https://github.com/rustyrussell/bitcoin-iterate/blob/master/doc/bitcoin-iterate.1.txt  But thanks for the blocksci pointer!
18 2018-03-24 05:08:06	0|midnightmagic|\o
19 2018-03-24 07:10:38	0|intcat|in bitcoin core, are RBF transactions that are replaced removed entirely from the mempool? or are they kept around until either one confirms?
20 2018-03-24 07:37:10	0|Varunram|intcat: the idea is that if a miner sees a higher tx fee, he is more likely to pick it up, so yeah, they are around until either one confirms
21 2018-03-24 07:39:53	0|intcat|Varunram: im asking about the original (lower fee) tx; replacement implies that this one is removed (to make place for the higher fee tx) but i am not sure if it's possible to do that deterministically
22 2018-03-24 07:53:43	0|sipa|h
23 2018-03-24 07:54:16	0|sipa|intcat: the mempool tries to represent a node's best guess for what will be confirmed
24 2018-03-24 07:56:05	0|intcat|sipa: so only one of the options is kept?
25 2018-03-24 07:56:28	0|sipa|yes
26 2018-03-24 07:56:42	0|sipa|the mempool is always internally consistent
27 2018-03-24 07:56:52	0|sipa|it never contains conflicting transactions
28 2018-03-24 07:57:19	0|sipa|for the purposes of fast block relay (bip 152), the old version is kept around for a short period of time, though
29 2018-03-24 07:58:32	0|Varunram|thanks for correcting my understanding :)
30 2018-03-24 07:59:19	0|intcat|hmm
31 2018-03-24 08:00:13	0|intcat|i see, thanks for answering
32 2018-03-24 08:00:26	0|intcat|i suppose the mempool should just not be expected to be deterministic in the first place :P
33 2018-03-24 08:05:14	0|intcat|sipa: one followup; is an exception made for wallet transactions? listtransactions has an (undocumented) 'walletconflicts' return value
34 2018-03-24 08:12:52	0|intcat|(i am asking in the context of setting up a system that reactively CPFPs to an attempted double-spend via RBF)
35 2018-03-24 08:13:21	0|intcat|(although reading the RBF BIP more closely it seems that this may not work as there is no way to undo a RBF)
36 2018-03-24 08:14:00	0|sipa|intcat: you can have wallet transactions that aren't in the mempool
37 2018-03-24 08:15:29	0|intcat|that makes sense
38 2018-03-24 08:17:20	0|sipa|in general the wallet is independent from the rest of the node
39 2018-03-24 08:17:49	0|sipa|anything else would be a privacy leak
40 2018-03-24 08:18:07	0|sipa|if the node's operation would depend on whether transactions are yours or not
41 2018-03-24 09:32:58	0|intcat|sipa: yes, i am aware of that :) but i had figured it the other way around - node keeps all RBF "alternatives"
42 2018-03-24 09:33:42	0|intcat|will have to think more on this; the problem i am trying to figure out is if there is incoming RBF tx A0, and the sender doublespends as A1, i would want to build a CPFP tx B0 on top of A0 to "RBF back"
43 2018-03-24 09:34:11	0|intcat|i will have to do some testing but from my current reading of RBF policy this doesnt seem possible
44 2018-03-24 09:35:55	0|arubi|what does RBF has to do with it?
45 2018-03-24 09:36:24	0|arubi|rbf doesn't mean "double spending enabled".  you might as well run this "cpfp back" thing on any incoming transaction
46 2018-03-24 09:38:19	0|intcat|arubi: i mean if i get an incoming rbf-enabled tx, and later my nodes sees a doublespend using the rbf feature, i want to react to it
47 2018-03-24 09:38:51	0|intcat|i am not saying doublespends are the only use of rbf, but they are something to consider
48 2018-03-24 09:41:11	0|arubi|why only consider double spending of rpf enabled transactions?  it can happen even without rbf
49 2018-03-24 09:42:59	0|intcat|arubi: because i wont see them, because they are not usually propagated
50 2018-03-24 09:43:35	0|intcat|can't react to what i can't see, unfortunately
51 2018-03-24 09:47:51	0|arubi|so I don't understand, you said it yourself, by policy A0 has been replaced with A1, now how would B0 build on top of A0 if it's gone?
52 2018-03-24 09:48:22	0|intcat|arubi: because reality is relative and decentralized
53 2018-03-24 09:48:56	0|intcat|A0 is not absolutely gone
54 2018-03-24 09:49:05	0|intcat|just relatively gone from the perspective of rbf-respecting nodes
55 2018-03-24 09:49:39	0|arubi|sure you could relay A0 and B0 again, but these same nodes will be the same ones who will not propagate a double spend at all
56 2018-03-24 09:50:17	0|intcat|my intent is to re-replace A1 with A0 through B0's CPFP
57 2018-03-24 09:50:43	0|intcat|current bitcoin core policy does not facilitate that - i think. i mean to test this but now have to run
58 2018-03-24 09:51:32	0|arubi|right, it shouldn't allow replacing an RBF'ed tx with its previous lower fee version.   cheers, later
59 2018-03-24 09:53:09	0|intcat|arubi: one more thought - if A0 and B0 were already propagated, A1 would need to "bid higher" than the accumulated fees of A0 and B0, so in that case, the A1 of my scenario would not replace A0 and B0 because they have higher combined fee
60 2018-03-24 09:53:22	0|intcat|so it's a question of which tx out of A1 and B0 arrives first in rbf-respecting nodes
61 2018-03-24 09:53:38	0|intcat|imho the logic should be more RBAF - replace by accumulative fee
62 2018-03-24 09:53:40	0|arubi|you can assume that if A1 arrived to you, then it arrived to most nodes
63 2018-03-24 09:54:08	0|arubi|rbAf would allow for double spending too, if the double spender cpfp's instead of the defender
64 2018-03-24 09:54:44	0|intcat|sure, but at least the defender is able to defend
65 2018-03-24 09:54:55	0|intcat|it can go back and forth, i guess
66 2018-03-24 09:55:06	0|intcat|but rbf as-is does not have a "defender" at all because they cannot defend
67 2018-03-24 09:55:19	0|intcat|anyway really have to run now! thanks for the discussion :)
68 2018-03-24 09:55:20	0|arubi|I don't think it's realistic to consider such a scenario anyway.  it's the reason we wait for confirmations before providing goods
69 2018-03-24 09:55:27	0|arubi|cya :)
70 2018-03-24 12:12:02	0|bitcoin-git|13bitcoin/06master 14bc308ba 15Karl-Johan Alm: [CI]: bump travis timeout for make check to 50m
71 2018-03-24 12:12:02	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/02b7e8319aef...b43aba89e356
72 2018-03-24 12:12:03	0|bitcoin-git|13bitcoin/06master 14b43aba8 15MarcoFalke: Merge #12772: [CI]: bump travis timeout for make check to 50m...
73 2018-03-24 12:12:46	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12772: [CI]: bump travis timeout for make check to 50m (06master...06bump_travis_timeout) 02https://github.com/bitcoin/bitcoin/pull/12772
74 2018-03-24 12:17:42	0|bitcoin-git|13bitcoin/06master 1430d1a0a 15Jim Posen: Docs: Improve documentation on standard communication channels...
75 2018-03-24 12:17:42	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b43aba89e356...7466a26cab5d
76 2018-03-24 12:17:43	0|bitcoin-git|13bitcoin/06master 147466a26 15MarcoFalke: Merge #12760: Docs: Improve documentation on standard communication channels...
77 2018-03-24 12:18:34	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12760: Docs: Improve documentation on standard communication channels (06master...06communication-channels) 02https://github.com/bitcoin/bitcoin/pull/12760
78 2018-03-24 14:08:32	0|Chris_Stewart_5|Segwit txs don't require nVersion on the transaction to be set to anything do they?
79 2018-03-24 14:11:23	0|Chris_Stewart_5|the two version bytes are after the nVersion on the tx?
80 2018-03-24 21:08:17	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #12633: Reserve 16 bits of nversion in blockheader (06master...06reservedbits) 02https://github.com/bitcoin/bitcoin/pull/12633
81 2018-03-24 22:22:35	0|bitcoin-git|[13bitcoin] 15jakubtrnka opened pull request #12774: Issue #10542 Signmessage doesn't work with segwit addresses (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/12774
82 2018-03-24 23:40:03	0|bitcoin-git|[13bitcoin] 15Christewart opened pull request #12775: Integration of property based testing into Bitcoin Core (06master...06rapidcheck_build) 02https://github.com/bitcoin/bitcoin/pull/12775