1 2014-12-20 01:17:52 <dgenr8> mempool art, 500+ tx all invalidated by a single respend http://i.imgur.com/ZTKAuqz.png
  2 2014-12-20 01:25:57 <phantomcircuit> dgenr8, what's that from?
  3 2014-12-20 01:41:04 <dgenr8> my mempool
  4 2014-12-20 01:45:54 <phantomcircuit> dgenr8, yeah but what tool visualized that
  5 2014-12-20 01:47:20 <dgenr8> ah here it is... https://github.com/weilu/bitcoin-tx-graph-visualizer
  6 2014-12-20 02:13:17 <kanzure> dgenr8: do you see that often?
  7 2014-12-20 02:16:49 <luke-jr_> I wonder if that was a legit respend or not
  8 2014-12-20 02:17:38 <dgenr8> kanzure: never before yesterday evening.  there were more than a dozen of these things.
  9 2014-12-20 02:18:21 <kanzure> so what sort of regular rate of transaction-invalidation do you see in your mempool?
 10 2014-12-20 02:18:54 <dgenr8> only 10-20 a day http://respends.thinlink.com
 11 2014-12-20 02:20:57 <dgenr8> a few weeks ago there was another pattern.  only 50 or so txes, but arranged in a dazzling self-referential mess
 12 2014-12-20 02:24:46 <luke-jr_> dgenr8: that's neat
 13 2014-12-20 02:24:51 <kanzure> yes.
 14 2014-12-20 02:25:35 <luke-jr_> what do the colours indicate?
 15 2014-12-20 02:27:43 <dgenr8> in the viz lib? nothing (I think).  there are some mods one would like to make, if one had time.  like making the channel widths represent amounts
 16 2014-12-20 02:30:41 <dgenr8> and representing vin/vout index, and leaving an unconnected part of the tx to represent fees, and...
 17 2014-12-20 03:38:27 <Keefe> would it be possible for me to check for the existence of a txn in the mempools of a large number of bitcoin nodes, to determine how well it propagated?
 18 2014-12-20 03:39:17 <Keefe> if i could write some script to use a list of nodes from getaddr.bitnodes.io, connect to a bunch of them, and send some sort of request for the txn?
 19 2014-12-20 03:40:29 <phantomcircuit> Keefe, you can connect to them and watch the inv broadcasts
 20 2014-12-20 03:40:47 <phantomcircuit> otherwise no
 21 2014-12-20 03:41:09 <Keefe> so i can only passively listen for re-broadcasts
 22 2014-12-20 03:42:04 <Keefe> do nodes usually periodically re-broadcast all txns in their mempool? or only ones they created?
 23 2014-12-20 03:46:42 <phantomcircuit> Keefe, only when they receive them
 24 2014-12-20 03:47:21 <Keefe> the reason i'm looking into this, is i'm trying to troubleshoot why i seem to be unsuccessful in broadcasting a new transaction to replace (same inputs) one i created almost 3 days ago with 0 fee. i thought surely by now the network would forget about the old txn that'll almost certainly never confirm, since the wallet that created it is no longer broadcasting
 25 2014-12-20 03:54:36 <user7779_> Keefe: you can monitor mempool txs here: http://mempool.info/
 26 2014-12-20 03:54:40 <user7779_> scroll down for older txs
 27 2014-12-20 03:55:17 <maaku> user7779_: you can monitor *someone else's* mempool transactions there
 28 2014-12-20 03:55:29 <user7779_> yes, pardon. should have ben more clear!
 29 2014-12-20 03:55:47 <user7779_> we are working on adding a few more nodes to it so it has a better spread
 30 2014-12-20 03:57:49 <Keefe> user7779_: nice, thx. scary though that there are txns from months ago still stuck in limbo, wasting space in mempools
 31 2014-12-20 03:58:09 <user7779_> yep!
 32 2014-12-20 03:59:07 <Keefe> i hope that's only due to the sender and/or receiver continuing to rebroadcast, and not just the network echoing the txns around and around
 33 2014-12-20 03:59:36 <user7779_> they don't "echo" them around. they get put in the mempool and they sit there unless they get kicked out or the node gets turned off
 34 2014-12-20 04:00:14 <Keefe> or pruned after some time, right?
 35 2014-12-20 04:00:51 <user7779_> i think you have the terminology a bit confused
 36 2014-12-20 04:01:22 <user7779_> pruning has nothing to do with the mempool. pruning is usually used in regards to the blockchain itself
 37 2014-12-20 04:01:31 <user7779_> removing data from it that a node might not need to be operational
 38 2014-12-20 04:01:34 <Keefe> ya, my bad choice of word
 39 2014-12-20 04:02:11 <user7779_> im not sure if there is a time limit wherein a tx will be removed from the mempool. a node can choose not to accept a tx into its mempool, that is for sure
 40 2014-12-20 04:02:29 <Keefe> so to be clear, you're saying a txn remains in a node's mempool indefinitely until restart or inclusion in a block. ouch
 41 2014-12-20 04:02:46 <maaku> Keefe: what else should happen?
 42 2014-12-20 04:02:51 <user7779_> yes, unless someone here says otherwise. that is my understanding
 43 2014-12-20 04:03:03 <Keefe> maaku: drop after a couple days?
 44 2014-12-20 04:03:10 <maaku> Keefe: why?
 45 2014-12-20 04:03:13 <user7779_> Keefe: no, that is not the behavior
 46 2014-12-20 04:03:39 <gmaxwell> Keefe: The mempool is naturally limited by fees/priority.
 47 2014-12-20 04:03:51 <Keefe> if no miner processes a txn for days, why waste memory if the sender/receiver don't care to keep it alive?
 48 2014-12-20 04:04:09 <gmaxwell> Keefe: expiry at some threshold may makes sense, but it would create double spending races and make it harder for lower priority txn to ever get mined.
 49 2014-12-20 04:04:49 <gmaxwell> Keefe: perhaps "mem" is causing confusion. There isn't any particular reason the mempool needs to be in ram.
 50 2014-12-20 04:04:57 <Keefe> ok
 51 2014-12-20 04:05:10 <user7779_> gmaxwell: then why is it?
 52 2014-12-20 04:05:21 <user7779_> kept in RAM
 53 2014-12-20 04:05:46 <maaku> user7779_: because that's how it is currently implmented
 54 2014-12-20 04:06:03 <user7779_> okay, so no constrains beyond that. interesting!
 55 2014-12-20 04:06:09 <gmaxwell> user7779_: because it's small enough that it doesn't matter if its not, and doing otherwise is more complex. I would expect it would be backed by disk eventually. (I suppose today it is somewhat in that large swaths of it will happily get swapped out)
 56 2014-12-20 04:06:34 <user7779_> perhaps if there is a DOS against the mempool it will become a bigger problem sooner than we think
 57 2014-12-20 04:06:36 <user7779_> hopefully not!
 58 2014-12-20 04:06:41 <Keefe> by "limited by fees/priority" do you mean there's usually a fixed size of the mempool so lowest fee/priority txns can fall off if there's a bunch of new unconfirmed txns?
 59 2014-12-20 04:07:19 <gmaxwell> Keefe: no but transactions below a certian threshold won't enter the mempool (and/or are very narrowly rate limited)
 60 2014-12-20 04:07:38 <gmaxwell> and the ability to create fees/priority is limited by the existing utxo set.
 61 2014-12-20 04:13:53 <Keefe> am i correct that most nodes/miners do not yet implement replace-by-fee or child-pays-for-parent?
 62 2014-12-20 04:14:47 <gmaxwell> Keefe: correct. (not sure why you say 'yet' as if its foregone tha these are desirable things!)
 63 2014-12-20 04:32:29 <Keefe> gmaxwell: i know my perspective is currently narrow, searching for hope of recovering the btc i sent without fee. either of those "features" would solve my problem
 64 2014-12-20 04:32:51 <Keefe> (between my own two wallets btw)
 65 2014-12-20 04:47:25 <gmaxwell> Keefe: it'll either go through or you can just conflict it. no need for hope, just logic. nodes don't mempool things that are too outragiously low, and priority goes up over time, nodes get restarted.
 66 2014-12-20 04:47:45 <gmaxwell> I've had no difficulty in the past conflicting .stuck transactions.
 67 2014-12-20 04:48:19 <gmaxwell> Just stop reannouncing the original, wait a few hours, write a conflicting one.. broadcast that.. maybe help it along using the eligius push interface.
 68 2014-12-20 04:58:29 <Keefe> gmaxwell: the original free txn was sent from a bci wallet a few days ago, bci dropped it after about 50 hours. that was about 20 hours ago. about 16 hours ago, i created a new txn from the bci wallet with the same inputs and with a proper fee. that's what i'm struggling to get to confirm
 69 2014-12-20 04:59:28 <Keefe> i've tried pushing the new txn to blockr.io, and one or two others, and from one of my own qt nodes. no luck yet. i thought eligius stopped providing a web push interface...
 70 2014-12-20 05:00:51 <Keefe> a few other blockchain explorers still see the old free txn and not the new one
 71 2014-12-20 05:08:12 <phantomcircuit> Keefe, connect to all the nodes you can connect to and push the tx to them
 72 2014-12-20 05:08:13 <phantomcircuit> :P
 73 2014-12-20 05:08:59 <Keefe> ok, will try :)
 74 2014-12-20 05:11:30 <wizkid057> Keefe: gmaxwell: I've temporarily disabled the web push interface on Eligius since some spam was getting through and I haven't had the time to fix it yet :(
 75 2014-12-20 05:21:20 <Keefe> my problem will be solved soon, thanks to wizkid057 :)
 76 2014-12-20 05:21:20 <Luke-Jr> (but wizkid057 and I can manually submit things)
 77 2014-12-20 05:21:48 <Luke-Jr> also, Eligius has had CPFP for like a year or two now
 78 2014-12-20 05:22:05 <Keefe> oh, nice to know
 79 2014-12-20 05:22:37 <Luke-Jr> (though it's hard to use since you need to get the tx to the mempool)
 80 2014-12-20 05:26:43 <Keefe> i think that would've been no (technical) problem in my case. eligius already had the free txn in its mempool, and i assume a child txn shouldn't have a problem propagating. but actually in my case, making a child txn would involve unsealing a priv key, so i hoped to avoid that
 81 2014-12-20 06:17:12 <Luke-Jr> Keefe: i c, makes sense
 82 2014-12-20 09:30:50 <maaku> gmaxwell: what's the protocol for reserving bip ranges
 83 2014-12-20 09:30:53 <maaku> ?
 84 2014-12-20 09:31:59 <phantomcircuit> maaku, ask for one
 85 2014-12-20 09:37:11 <maaku> ok, I have a range of six BIPs that i'm working on, on the topics of (1) Merklized prefix trees, (2) data commitment and proof structure, (3) improved merged, mining, (4) block header back-link commitments, (5) UTXO commitments, and (6) TXO commitments
 86 2014-12-20 09:37:49 <maaku> still drafting the text and reference implementations, but allocating a contiguous sequence of BIP numbers would be nice
 87 2014-12-20 09:39:58 <maaku> actually could be 7 since (2) is two topics (unvalidated data commitments, and the generic serialization format for commitments proofs)
 88 2014-12-20 10:05:56 <maaku> grrr CPartialMerkleTree could be much more efficient
 89 2014-12-20 10:09:24 <gmaxwell> I've had bad expirences with ranges and reservations. There is no great advantage in having them contigious, really, I'd rather take them as they come.
 90 2014-12-20 10:10:01 <maaku> ok
 91 2014-12-20 13:25:34 <aschildbach> Are there any statistics about how many transactions follow the BIP62 rules these days? Specifically the "DER encoding" and "low S value" rules?
 92 2014-12-20 13:26:43 <sipa> i don't know; not many, i expect
 93 2014-12-20 13:26:56 <sipa> bitcoinj/bitcoin core?
 94 2014-12-20 13:30:25 <aschildbach> sipa: On the blockchain.
 95 2014-12-20 13:30:42 <aschildbach> sipa: Or rather in the P2P network.
 96 2014-12-20 13:30:51 <aschildbach> Doesn't matter which client
 97 2014-12-20 13:31:02 <sipa> sure; i mean i don't have numbers, but i expect only core/bitcoinj are creating low S value signatures
 98 2014-12-20 13:31:10 <sipa> DER encoding... everyoe
 99 2014-12-20 13:31:41 <sipa> not following DER has been non-standard since 0.8, and afaik there are exactly 0 transactions being created anymore that don't follow that rule
100 2014-12-20 13:43:37 <aschildbach> Ok thanks
101 2014-12-20 14:11:04 <jonasschnelli> kanzure, gmaxwell: fundrawtransaction: what would the optional limit parameter do?
102 2014-12-20 14:13:20 <kanzure> 13:25 < gmaxwell> hm. wouldn't it be nice if you could say   "createraw [] {dest:10}  ; fundraw hex limit=5; signraw anyonecanpay" then pass it to someone wlse who can fundraw; signraw; sendraw?
103 2014-12-20 14:13:46 <sipa> jonasschnelli: not funny fund
104 2014-12-20 14:13:48 <sipa> *fully
105 2014-12-20 14:13:59 <kanzure> funny fund, where you pay with clown points
106 2014-12-20 14:14:06 <sipa> but only fund up to a certain amount, allowing others to add funds
107 2014-12-20 14:14:14 <lewellyn> don't give the altcoins any ideas, kanzure :P
108 2014-12-20 14:14:28 <sipa> cloiwn
109 2014-12-20 14:14:41 <jonasschnelli> sipa and not adding a change vout?
110 2014-12-20 14:16:13 <kanzure> jonasschnelli: however, my idea for fundmany was refuted here http://bitcoinstats.com/irc/bitcoin-dev/logs/2014/12/19#l1419025192
111 2014-12-20 14:17:00 <jonasschnelli> kanzure: yes i saw that. But the LIMIT param still makes sense to me
112 2014-12-20 14:18:51 <jonasschnelli> sipa: okay. i think i got it. Fill up the transaction with coins till we are > given LIMIT, add change vout that we reach = LIMIT? Who pays the fee?
113 2014-12-20 14:19:14 <sipa> jonasschnelli: for gmaxwell's example, you can't add change
114 2014-12-20 14:19:38 <sipa> as that will invalidate the signatures
115 2014-12-20 14:20:54 <jonasschnelli> but lets assume, bob has only one 50BTC coin left unspent. He not fundraw a 30BTC tx with LIMIT 15BTC, how does he get his change (30-15)?
116 2014-12-20 14:21:05 <jonasschnelli> He not = He now
117 2014-12-20 14:21:37 <sipa> you can create a transaction to break up the coin beforehand :)
118 2014-12-20 14:21:54 <jonasschnelli> yes. i thought about that... :)
119 2014-12-20 14:21:56 <sipa> not a serious suggestion, but i don't see a good way to deal with it otherwise
120 2014-12-20 14:22:47 <kanzure> malleability will bust that
121 2014-12-20 14:23:06 <sipa> you can do it manually too, and wait for it to confirm beforehand
122 2014-12-20 14:23:33 <kanzure> and also, the docstrings around fundrawtransaction would have to scream "this may make an initial transaction with a separate txid"
123 2014-12-20 14:23:35 <sipa> yeah, not suggesting that fundrawtransaction itself does it
124 2014-12-20 14:23:57 <sipa> but if not, you're already manually choosing coins to add anyway
125 2014-12-20 14:24:06 <sipa> so fundrawtransaction seems meaningless
126 2014-12-20 14:24:37 <kanzure> actually that's pretty funny. right, use sendtoaddress to send to your own address first, then specifically use that vout :).
127 2014-12-20 14:24:48 <jonasschnelli> LIMIT makes only sense if there would be a ways to break coins before the fund takes place...
128 2014-12-20 14:25:53 <jonasschnelli> and what about the txfee? Last user who add funds to the tx need to pay the fees?
129 2014-12-20 14:27:39 <Belxjander> jonasschnelli spread the fee amongst everyone?
130 2014-12-20 14:28:42 <jonasschnelli> Belxjander: how? IMO the fee can only be calculated after the last vin has added.
131 2014-12-20 20:16:40 <chmod755> Bitcoin needs to dissolve Cody Wilson
132 2014-12-20 20:41:28 <Luke-Jr> chmod755: please keep off-topic not in here
133 2014-12-20 20:44:30 <chmod755> :X
134 2014-12-20 20:50:46 <jcrubino> is there a server for dns lookup (nslookup) of testnet peers?
135 2014-12-20 20:53:05 <sipa> yes
136 2014-12-20 20:53:08 <chmod755> jcrubino, testnet-seed.bitcoin.petertodd.org
137 2014-12-20 20:53:17 <jcrubino> thanks
138 2014-12-20 21:10:11 <BlueMatt_> well, I submitted this as a test just to see if it would work....but what do people think about this: https://github.com/bitcoin/bitcoin/pull/5515
139 2014-12-20 21:11:04 <BlueMatt> it essentially asserts that we dont have deadlocks assuming: (a) no locking-conditions are based on data other than the current set of locked locks and (b) if we do a TRY_LOCK, and it fails, we will immediately bail out and just skip that section of code
140 2014-12-20 21:11:09 <BlueMatt> both of which are pretty reasonable assumptions
141 2014-12-20 21:11:29 <BlueMatt> considering DEBUG_LOCKORDER is essentially only a travis-thing I dont really mind if its not entirely stable?
142 2014-12-20 21:13:28 <BlueMatt> I have another commit which will not assert if you try_lock on a lock which is not a part of the lock mis-order, but that also doesnt seem to be needed and may be more accepting of real deadlocks
143 2014-12-20 21:34:26 <jonasschnelli> BlueMatt regarding your idea for XORed ip DNS, how you would deploy this? How you would support old versions? New DNS servers for a new bitcoind version?
144 2014-12-20 21:35:03 <BlueMatt> jonasschnelli: yea, just a new subdomain
145 2014-12-20 21:35:11 <gmaxwell> jonasschnelli: just a new domain name for the new form, eventually retire the old ones.
146 2014-12-20 21:35:14 <BlueMatt> also, not my idea
147 2014-12-20 21:35:52 <gmaxwell> BlueMatt: forgodssake I sure as heck don't want credit for it. :P
148 2014-12-20 21:36:04 <jonasschnelli> the xored ip is a valid ip? So it could be possible that the xored ip also serves malware?
149 2014-12-20 21:36:10 <BlueMatt> gmaxwell: nor do I
150 2014-12-20 21:36:34 <BlueMatt> jonasschnelli: yes, but if you're clever, you should be able to pick an xor mask to reduce the risk
151 2014-12-20 21:36:54 <BlueMatt> also, it becomes $(RANDOM_IP_SERVES_MALWARE), not $(IP_WITH_ACTIVE_SERVERS_SERVS_MALWARE)
152 2014-12-20 21:37:02 <BlueMatt> which is much better
153 2014-12-20 21:37:15 <gmaxwell> jonasschnelli: perhaps, but pretty unlikely.
154 2014-12-20 21:37:58 <gmaxwell> the right mask choice could get a lot of the routable internet into multicast space... though we might want to make sure that no common recursive resolvers are blocking results like that.
155 2014-12-20 21:38:13 <gmaxwell> probably should have some effort to avoid returning private blocks, for example.
156 2014-12-20 21:40:17 <jonasschnelli> it could be more complex then just a xor mask
157 2014-12-20 21:42:28 <BlueMatt> could be, but.....
158 2014-12-20 21:44:41 <gmaxwell> jonasschnelli: sure, could be whitned by going lsb to msb and xoring each new bit with some arbritary function on the prior bits.
159 2014-12-20 21:45:58 <gmaxwell> to reduce blocking of weird address space, the most significant byte could be left alone.
160 2014-12-20 21:48:23 <jonasschnelli> gmaxwell sound good. And the quasi standard software for bitcoin dnsseed is sipas thing? https://github.com/sipa/bitcoin-seeder
161 2014-12-20 21:49:26 <Aquent> do we have any estimate of when sidechains might be implemented? Like if reddit wanted to adopt sidechains to issue reddit notes, how long would you estimate this would take?
162 2014-12-20 21:58:47 <BlueMatt> jonasschnelli: no, there are like 4 seed scanners/seed implementations at this point....
163 2014-12-20 21:59:00 <BlueMatt> jonasschnelli: if you're looking to implement, just do it in bitcoin core, the rest will follow
164 2014-12-20 22:23:49 <aschildbach> jonasschnelli: whatever you do, please do not implement another DNS server. Rather generate zonefiles for e.g. bind.
165 2014-12-20 22:40:13 <wbic16> What's the most common platform used for bitcoin core dev (which distro)?
166 2014-12-20 22:50:35 <wbic16>  /ping, anyone watching irc today? :)
167 2014-12-20 22:57:57 <gmaxwell> wbic16: Who knows?
168 2014-12-20 22:58:12 <gmaxwell> wbic16: in terms of running hosts, I wouldn't be surprised if it were windows. :)
169 2014-12-20 22:58:19 <wbic16> no, I meant for dev
170 2014-12-20 22:59:33 <gmaxwell> dunno, all work about equally well, on some you have to kick openssl's ecc support. I use fedora and gentoo, several people use ubuntu, at least one person uses arch.
171 2014-12-20 22:59:49 <wbic16> gotcha