1 2015-12-14 05:23:01 <jl2012> rusty: Actually, I don't even think my proposal should be discussed in bitcoin-dev list in the first place. It's mostly suitable for bitcointalk, but its dev section is basically dead.
  2 2015-12-14 05:29:48 <jl2012> A forum like bitcointalk has many benefits for such dicussions: 1. it's better for short and rapid response; 2. it's possible to edit a proposal; 3. do not need to send to everybody's inbox.
  3 2015-12-14 05:31:57 <jl2012> Devs and experts have been very active in the forum, but now most of them are gone. I think the reason is that the SNR is becoming too bad as people are spamming just to promote their ad sig.
  4 2015-12-14 05:35:20 <jl2012> If we could have a section that only a sub-group of people may start a new thread, and thread starter could self-moderate by default, do you think more experts would join discussion there?
  5 2015-12-14 05:41:02 <phantomcircuit> jl2012, unfortunately bitcointalk has been almost entirely abandoned by serious developers
  6 2015-12-14 05:42:30 <jl2012> phantomcircuit: I understand why it is abandoned, but I don't see why we can't revive it
  7 2015-12-14 05:42:59 <jl2012> We have IRC for instant discussion, but very poor documentation
  8 2015-12-14 05:44:18 <jl2012> We have mailing list for very good documentation, but not good for meticulous discussion and debate
  9 2015-12-14 05:44:49 <Luke-Jr> jl2012: I think reddit's design makes more sense
 10 2015-12-14 05:44:51 <jl2012> A forum should fill the gap: good documentation and meticulous discussion
 11 2015-12-14 05:47:06 <jl2012> Luke-Jr: I'm fine with either reddit or bitcointalk
 12 2015-12-14 05:47:23 <Luke-Jr> actually, forums don't seem very good for documentation either
 13 2015-12-14 05:47:28 <Luke-Jr> IRC + wiki maybe the best :p
 14 2015-12-14 05:48:31 <jl2012> Luke-Jr: At least I could still easily search the posts by Satoshi, also the debate of P2SH on bitcointalk
 15 2015-12-14 05:48:49 <Luke-Jr> personality cults are something to discourage, not encourage <.<
 16 2015-12-14 05:48:59 <Luke-Jr> much of P2SH was on IRC fwiw
 17 2015-12-14 05:50:02 <jl2012> Luke-Jr: Only a real archaeologist would look at IRC for P2SH debate
 18 2015-12-14 05:51:37 <jl2012> As I learnt bitcoin in mid-2012, all my knowledge related to OP_EVAL is coming from bitcointalk
 19 2015-12-14 05:57:47 <jl2012> So, my question is, would serious developers like to use a highly moderated bitcointalk section, or a bitcoin-wizards subreddit?
 20 2015-12-14 05:57:53 <Luke-Jr> scary, we probably all look like fools back then, in hindsight :P
 21 2015-12-14 06:02:06 <btcdrak> jl2012, just wanted to say thanks for the thoughtful posts to the dev list.
 22 2015-12-14 06:02:57 <btcdrak> jl2012, a subreddit would be ok for me, providing it is *highly* moderated so it doesn't get brigaded. Reddit is a terrible platform when participants are not acting in good faith.
 23 2015-12-14 06:03:49 <bitcoin-dev760> Hey..I am new to bitcoin codebase... Can anyone help me understand why we have InitHTTPServer and StartHTTPServer seperately in src/httpserver.cpp?
 24 2015-12-14 06:04:00 <btcdrak> jl2012: although bitcointalk.org is also a good place for discussion if that could be revived, it's as good as.
 25 2015-12-14 06:05:24 <Luke-Jr> btcdrak: can you imagine the drama though?
 26 2015-12-14 06:06:06 <btcdrak> judging by r/btc yes, but let them drama in their own sub!
 27 2015-12-14 06:08:32 <jl2012> Luke-Jr, btckdrak: if we could have a sub-section in bitcointalk, that only allows dicussion of ideas from the bitcoin-dev list, would that be helpful?
 28 2015-12-14 06:08:59 <btcdrak> jl2012 either way works for me. You need to convince devs to participate. Reddit might be better
 29 2015-12-14 06:09:13 <btcdrak> I created a sub incase someone hijacked it, I'll hand it over to you
 30 2015-12-14 06:09:34 <Luke-Jr> I am mostly satisfied with ML + IRC for now, but I wouldn't object.
 31 2015-12-14 06:09:48 <btcdrak> jl2012: your idea though, you decide what you want to try and try to market it
 32 2015-12-14 06:55:20 <btcdrak> 55 blocks until we can OP_HODL on mainnet!
 33 2015-12-14 07:38:13 <jl2012> btcdrak: what is the earliest height for that?
 34 2015-12-14 07:40:53 <btcdrak> jl2012: I think it's block #387367
 35 2015-12-14 07:41:54 <btcdrak> jl2012: providing someone doesnt produce a v3 block before then of course. anyway, it's maybe +1 of that block or +2 if we're really unlucky
 36 2015-12-14 07:48:05 <jl2012> btcdrak: thanks. I guess you are refering to #388367
 37 2015-12-14 07:49:37 <btcdrak> jl2012: yeah derp! 50 blocks from the current block now.
 38 2015-12-14 07:50:06 <btcdrak> jl2012: so block #388353
 39 2015-12-14 07:56:54 <jl2012> I don't think it's 388353
 40 2015-12-14 07:57:15 <jl2012> the 50th v3 is 387380, the 51th v3 is 387366
 41 2015-12-14 07:57:55 <jl2012> should be 388367?
 42 2015-12-14 07:58:04 <jl2012> the 51th v3 + 1001?
 43 2015-12-14 08:08:24 <jl2012> I think it's right. If all blocks until 388366 are v4, 388367 is the first block that must be v4
 44 2015-12-14 09:12:24 <jl2012> an anonymous miner found a v3. Deployment delayed to block 387381
 45 2015-12-14 09:12:29 <jl2012> 388381
 46 2015-12-14 09:51:27 <veggi3> hi
 47 2015-12-14 09:51:34 <veggi3> why are you guys removing priority?
 48 2015-12-14 10:02:19 <btcdrak> jl2012: I calculated by counting the number of block required for the remaining v3 blocks to drop off so there are 950 v4 blocks out of 1000, then add that number to the current blocknumber
 49 2015-12-14 10:03:24 <jl2012> btcdrak: if no further v3 is found, 388381 will be the first block that must be v4
 50 2015-12-14 10:05:10 <btcdrak> jl2012: I make it 388377. today for sure.
 51 2015-12-14 10:06:09 <jl2012> i think you count it in a wrong way
 52 2015-12-14 10:06:26 <jl2012> no matter what, it must not be 388377
 53 2015-12-14 10:07:21 <btcdrak> well if I am a block out, it would be 388383
 54 2015-12-14 10:07:25 <jl2012> it might be 388377 only if we have a v3 around 387377, but no v3 there
 55 2015-12-14 10:07:49 <jl2012> also not possible for 388383
 56 2015-12-14 10:07:52 <veggi3> if you take out priority from bitcoin, what is going to happen when all the bitcoin users protest and dont pay fees anymore?
 57 2015-12-14 10:08:07 <jl2012> I'm quite sure it is 388381
 58 2015-12-14 10:08:10 <veggi3> i can make a movement to protest this and then bitcoin will become insolvent
 59 2015-12-14 10:08:34 <btcdrak> veggi3: seems rather dramatic
 60 2015-12-14 10:08:48 <veggi3> i thought most chinese miners dont pay fees, no?
 61 2015-12-14 10:09:06 <veggi3> so isn't this a racist idea anyways? to get rid of the chiense?
 62 2015-12-14 10:09:45 <veggi3> who is behind this idea to get rid of priority anyways?
 63 2015-12-14 10:09:48 <veggi3> what are their names?
 64 2015-12-14 10:10:13 <veggi3> this idea is worse than xt
 65 2015-12-14 10:11:24 <jl2012> btcdrak: the activation height should be the height of 51st v3 block + 1001
 66 2015-12-14 10:11:36 <btcdrak> veggi3: please take this to #bitcoin
 67 2015-12-14 10:13:09 <btcdrak> jl2012: I just wish it would hurry up, I want to broadcast my OP_HODL!
 68 2015-12-14 10:14:24 <btcdrak> jl2012: trying to convince coinb.in to create some templates so people can start using HODL to do escrow and stuff. Do you know any js programmers?
 69 2015-12-14 10:15:03 <jl2012> it should have been an hour or so earlier, if there has not been a v3 recently
 70 2015-12-14 10:15:45 <jl2012> I don't want to miss the drama, in case we have an SPV mining fork again
 71 2015-12-14 10:21:08 <jl2012> btcdrak: I'm not a programmer and either know a suitable one....
 72 2015-12-14 10:22:35 <jl2012> countdown to BIP65: 48 blocks
 73 2015-12-14 11:34:57 <T3Xploit> @sipa you around?
 74 2015-12-14 11:35:05 <sipa> yes
 75 2015-12-14 12:16:26 <jl2012> sipa: I think we have to be very careful when applying the "exactly one true value" rule in segwit
 76 2015-12-14 12:17:17 <jl2012> This immediately kills my proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011952.html
 77 2015-12-14 12:20:06 <jl2012> and also the proposal of putting the location of input in the witness
 78 2015-12-14 12:22:33 <gmaxwell> jl2012: no it doesn't.
 79 2015-12-14 12:22:48 <gmaxwell> the location is just part of the utxo data. (it already is today)
 80 2015-12-14 12:23:35 <jl2012> I'm talking about the fraud proof in sipa's talk
 81 2015-12-14 12:24:23 <jl2012> http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
 82 2015-12-14 12:24:48 <gmaxwell> jl2012: I know what you're talking about, and you're incorrect.
 83 2015-12-14 12:24:48 <jl2012> search for "you can instead make the witness contain the height of the block which produced the outputs"
 84 2015-12-14 12:25:01 <gmaxwell> Yes, which is already part of the txouts.
 85 2015-12-14 12:25:17 <gmaxwell> It's needed for the maturity check, and will also be needed for relative locktime.
 86 2015-12-14 12:25:49 <gmaxwell> So it would need to be part of the data that your above post carries with it already.
 87 2015-12-14 12:26:06 <jl2012> but this is not committed to the block
 88 2015-12-14 12:27:12 <gmaxwell> You must still obtain it to verify, so you must still know it when you prepare your block, so you can stil provide it in the witness.
 89 2015-12-14 12:27:38 <jtoomim> has BIP248 been implemented? If so, can someone point me to the code?
 90 2015-12-14 12:27:52 <gmaxwell> jtoomim: there is no such bip.
 91 2015-12-14 12:27:58 <jtoomim> i know
 92 2015-12-14 12:28:01 <jtoomim> it's a nickname
 93 2015-12-14 12:28:04 <jtoomim> so no code yet?
 94 2015-12-14 12:29:06 <jl2012> as I understand, in sipa's talk, he refered to comitting these info to the blockchain through the witness
 95 2015-12-14 12:29:28 <jl2012> it's for SPV, not for full nodes
 96 2015-12-14 12:29:55 <sipa> it's for fraud-proof-checking full nodes; SPV nodes can't verify fraud proofs
 97 2015-12-14 12:30:06 <sipa> (or at least, you need to see full blocks)
 98 2015-12-14 12:30:56 <jl2012> sipa: Full nodes by definition verifies the whole chain. Why do they need "fraud proof"?
 99 2015-12-14 12:32:17 <gmaxwell> Thats a little terminiology mangled.
100 2015-12-14 12:32:29 <gmaxwell> Lite nodes don't verify the additional witness information.
101 2015-12-14 12:32:43 <gmaxwell> But it allows a full node to generate a compact fraud proof that a lite node can verify.
102 2015-12-14 12:33:35 <jl2012> lite node = SPV node?
103 2015-12-14 12:33:58 <gmaxwell> lite nodes don't generally pay any attention to the witness commitment themselves. (except in so far as data from them may be used to produce a fraud proof. Or an "alert" in the whitepaper terminology)
104 2015-12-14 12:34:07 <gmaxwell> Yes.
105 2015-12-14 12:36:44 <gmaxwell> jl2012: e.g. a block spends an input that never existed. You want to convince a lite node of this. Today you can't.  With the additional commitment, you reveal the backpointer to the txout creation, and then the data at that location (or a proof there is no data there, e.g. block too small).
106 2015-12-14 12:36:49 <jl2012> this is how I understand that part of sipa's talk: as a consensus rule, the witness must contain a pointer to the location of the input. The tx is invalid if the pointer is incorrect. If a malacious miner tries to spend a non-existing input, a full node could generate a compact proof, showing that the pointer committed in the witness does not point to right place.
107 2015-12-14 12:37:10 <gmaxwell> Correct.
108 2015-12-14 12:37:12 <sipa> my terminology is confused: but to verify a fraud proof, you have to see the entire block (all the "corruption possible" checks have to hold)
109 2015-12-14 12:37:41 <sipa> otherwise a miner could have constructed a block with a transaction that does not exist, and never publish it
110 2015-12-14 12:38:15 <jl2012> gmaxwell: ok, so the backpointer must be committed to the block, or SPV node can't verify the backpointer
111 2015-12-14 12:38:24 <gmaxwell> jl2012: correct.
112 2015-12-14 12:38:33 <gmaxwell> jl2012: and this is not incompatible with your scheme.
113 2015-12-14 12:38:35 <sipa> you need something stronger than SPV i mean
114 2015-12-14 12:38:59 <jl2012> gmaxwell: "and this is not incompatible with your scheme." <-------- you misunderstood me
115 2015-12-14 12:39:10 <gmaxwell> jl2012: okay? help me understand.
116 2015-12-14 12:39:21 <jl2012> wait a moment
117 2015-12-14 12:40:12 <jl2012> gmaxwell: I'm talking about this: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011962.html
118 2015-12-14 12:40:34 <jl2012> search "a single TRUE"
119 2015-12-14 12:41:06 <jl2012> I said "a single TRUE" is incompatible with my proposal and the committment proposal
120 2015-12-14 12:41:44 <sipa> hmm, help me understand that?
121 2015-12-14 12:42:31 <gmaxwell> Oh. jl2012 wants to add his additonal witness by stuffing in the existing witness field; instead of just adding a new witness type.
122 2015-12-14 12:42:41 <sipa> oh
123 2015-12-14 12:42:58 <sipa> you can just define new witness fields the same this one is being added
124 2015-12-14 12:43:06 <gmaxwell> I think it would be better to accomplish your proposal with an additional witness.
125 2015-12-14 12:43:30 <sipa> newer script versions may treat the witness data very differently anyway
126 2015-12-14 12:43:48 <sipa> you can't assume that adding more data at the end or beginning will always be possible
127 2015-12-14 12:43:50 <jl2012> so you both forsee we will have mutliple witness in the future?
128 2015-12-14 12:44:13 <sipa> plus not knowing what the data represents is terrible for dos protection
129 2015-12-14 12:45:16 <gmaxwell> Yes, unification of witnesses should only be important for getting them into a single commitment struture where its useful to do that.
130 2015-12-14 12:45:33 <jl2012> segregating segregated witness
131 2015-12-14 12:46:00 <gmaxwell> It's turtles all the way down.
132 2015-12-14 12:53:25 <jl2012> um....maybe you both are right.....but that means more hash trees to maintain
133 2015-12-14 12:54:51 <gmaxwell> jl2012: does what you're suggesting even need a commitment at all? I did not think it did.
134 2015-12-14 12:55:36 <jl2012> gmaxwell: commitment is needed, again for fraud proof
135 2015-12-14 12:56:14 <jl2012> I haven't think carefully about fraud proof yet. But at least a committment is needed
136 2015-12-14 12:56:26 <jl2012> necessary but may not be sufficient
137 2015-12-14 12:56:39 <gmaxwell> I don't think one is actually needed there.
138 2015-12-14 12:57:29 <gmaxwell> Or rather, the stxo part might so nevermind, hadn't unified those in my mind.
139 2015-12-14 12:57:42 <gmaxwell> In any case, it's reasonable that its a seperate tree.
140 2015-12-14 13:02:36 <jl2012> I'm fine if more trees will be allowed.
141 2015-12-14 13:03:14 <sipa> i haven't responded to that part of the mail, but for the block commitments i propose (suggested by luke) to use namecoin-style commitments
142 2015-12-14 13:03:18 <jl2012> I wrote this proposal before I learnt segwit. My plan was to put these membership proof in scriptSig
143 2015-12-14 13:03:42 <sipa> where the coinbase (or something else) contains a nonce, a tree size, and a root
144 2015-12-14 13:04:07 <sipa> and there is a deterministic algorithm that given size and nonce determines where in a merkle tree its commitment goes
145 2015-12-14 13:04:31 <sipa> this lets you add nearly unlimited commitments in one hasb
146 2015-12-14 13:04:48 <sipa> while guaranteeing that there is still only one commitment for each type of data
147 2015-12-14 13:06:34 <jl2012> sipa: any paper for this scheme? or the name?
148 2015-12-14 13:08:16 <sipa> jl2012: https://github.com/sipa/bitcoin/commit/c5d28fa431e30ac6a85d02c60f11666273a04bf0 (see the block of comments)
149 2015-12-14 13:11:47 <jl2012> what is aa21a9ed? just a random magic number?
150 2015-12-14 13:13:07 <sipa> yup
151 2015-12-14 13:14:04 <sipa> it's inspired by namecoin, though namecoin's algorithm for determining the commitment position is actually broken
152 2015-12-14 13:20:34 <jl2012> So you are putting the witness root hash inside an expandable Merkle tree, and commit the root hash of the Merkle tree in coinbase?
153 2015-12-14 13:21:25 <sipa> yup
154 2015-12-14 13:21:56 <sipa> i don't have strong opinions on where the root should go, though
155 2015-12-14 13:22:10 <sipa> maybe a separate coinbase output is easier
156 2015-12-14 13:22:37 <jl2012> then P2Pool has to adapt, I believe
157 2015-12-14 13:22:59 <sipa> p2p can easily adapt, but indeed :)
158 2015-12-14 13:23:06 <sipa> * p2pool
159 2015-12-14 13:23:21 <sipa> i'm more worried about mining hardware
160 2015-12-14 13:24:05 <jl2012> I don't think any of those would use the outputs?
161 2015-12-14 13:24:27 <jl2012> but some may use coinbase?
162 2015-12-14 13:25:29 <sipa> maybe :)
163 2015-12-14 13:25:49 <sipa> i'm just no expert on that, so i welcome opinions
164 2015-12-14 13:28:18 <jl2012> Would you expect the "expandable merkle tree" is very deep? Otherwise, won't collision happen?
165 2015-12-14 13:28:52 <jl2012> I'm talking about this part: SHA256('WitnessV1\x00\x00\x00\x00\x00\x00\x00' || nonce)
166 2015-12-14 13:32:31 <jl2012> do you mean, if we have 2 witness root hash, the locator of the new one will be SHA256('WitnessV2\x00\x00\x00\x00\x00\x00\x00' || nonce)
167 2015-12-14 13:55:06 <jl2012> I think I get it. You will just pick a nonce that won't cause collision
168 2015-12-14 13:56:07 <jl2012> so all people will use the same nonce, unless they have more hash to committ than other people
169 2015-12-14 14:05:10 <Lightsword> does it look like p2pool will fork before the rest of the network does?
170 2015-12-14 14:34:58 <jl2012> only 17 blocks left
171 2015-12-14 14:35:05 <jl2012> for BIP65
172 2015-12-14 14:52:51 <btcdrak> praise be!
173 2015-12-14 15:17:47 <jl2012> no block in 27 minutes....
174 2015-12-14 15:18:03 <jl2012> the blockchain doesn't grow when you look at it
175 2015-12-14 15:18:04 <midnightmagic> ;;tblb [ calc 27 * 60 ]
176 2015-12-14 15:18:05 <gribble> The expected time between blocks taking 27 minutes and 0 seconds to generate is 3 hours, 22 minutes, and 47 seconds
177 2015-12-14 15:19:04 <jl2012> oh, just a new one. 13 blocks to go
178 2015-12-14 15:19:16 <btcdrak> gribble should be able to tell us when a softfork activates and enforces....
179 2015-12-14 15:19:23 <btcdrak> maybe he should even do a countdown :)
180 2015-12-14 15:20:02 <jl2012> is gribble a bot?
181 2015-12-14 15:21:21 <btcdrak> ;;help
182 2015-12-14 15:21:22 <gribble> The bot responds when you start a line with the ! character. A good starting point for exploring the bot is the !facts command. You can also visit the bot's website for a list of help topics and documentation: http://gribble.sourceforge.net/
183 2015-12-14 15:21:45 <btcdrak> jl2012 there's the link to his commands
184 2015-12-14 15:22:34 <btcdrak> jl2012: https://en.bitcoin.it/wiki/Gribble
185 2015-12-14 15:27:18 <instagibbs> jl2012, I had some mainnet-only issue once with a wallet i was debugging. Next block took 52 minutes :( never watch it
186 2015-12-14 15:32:08 <jl2012> https://en.wikipedia.org/wiki/Quantum_Zeno_effect
187 2015-12-14 15:37:31 <jl2012> 12 to go
188 2015-12-14 15:43:25 <jl2012> 11
189 2015-12-14 15:46:18 <btcdrak> just one v3 block would set us back another hour :/ fingers crossed
190 2015-12-14 15:49:17 <jl2012> 10!
191 2015-12-14 15:55:34 <jl2012> 9
192 2015-12-14 16:01:49 <jl2012> 8
193 2015-12-14 16:18:33 <jl2012> ;;tblb [ calc 17 * 60 ]
194 2015-12-14 16:18:35 <gribble> The expected time between blocks taking 17 minutes and 0 seconds to generate is 1 hour, 2 minutes, and 44 seconds
195 2015-12-14 16:24:51 <instagibbs> ;;tblb [ calc 45 * 60 ]
196 2015-12-14 16:24:53 <gribble> The expected time between blocks taking 45 minutes and 0 seconds to generate is 1 day, 4 hours, 6 minutes, and 2 seconds
197 2015-12-14 16:39:23 <jl2012> it's already 37 minutes...
198 2015-12-14 16:39:36 <jl2012> ;;tblb [ calc 37 * 60 ]
199 2015-12-14 16:39:38 <gribble> The expected time between blocks taking 37 minutes and 0 seconds to generate is 10 hours, 58 minutes, and 25 seconds
200 2015-12-14 16:40:07 <jl2012> a bad luck day
201 2015-12-14 16:40:51 <sipa> if itbhappens every 11 hours, it's hard it a bad luck day when it happens :)
202 2015-12-14 16:44:42 <btcdrak> 43 mins, glah. why amd I staring at this >.>
203 2015-12-14 16:49:02 <instagibbs> sipa, a watched poisson distribution never forgets
204 2015-12-14 16:49:11 <instagibbs> maybe mixing my metaphors here
205 2015-12-14 16:49:30 <harding> Two v4 blocks in a row.
206 2015-12-14 16:50:00 <btcdrak> if someone generates a v3 block now I will scream
207 2015-12-14 16:50:33 <jl2012> btcdrak: I will wish him keep mining v3 after the fork
208 2015-12-14 16:50:49 <jl2012> 6 left
209 2015-12-14 16:50:50 <btcdrak> jl2012: bwahahaha
210 2015-12-14 16:51:55 <jonasschnelli> 1 left? not?
211 2015-12-14 16:52:34 <jonasschnelli> 1 left? not?
212 2015-12-14 16:52:41 <jonasschnelli> (oops, wrong window)
213 2015-12-14 16:53:04 <harding> jonasschnelli: we're at 949/950, but the next 6 blocks all have to be v4 before a v3 block drops off the tail end of the window.
214 2015-12-14 16:53:28 <btcdrak> three I think
215 2015-12-14 16:53:44 <jonasschnelli> Okay. I see.
216 2015-12-14 16:54:03 <jl2012> btcdrak: bitcoinity's chart is wrong
217 2015-12-14 16:54:05 <btcdrak> watch 'bitcoin-cli getblockchaininfo | tail && bitcoin-cli getinfo'
218 2015-12-14 16:54:24 <petertodd> jonasschnelli: when does it unlock?
219 2015-12-14 16:54:27 <btcdrak> what's the txid?
220 2015-12-14 16:54:36 <jonasschnelli> haha... 2015-12-31... :) haha
221 2015-12-14 16:54:43 <btcdrak> hey petertodd, you came here for the blockparty!
222 2015-12-14 16:54:50 <jonasschnelli> but i also have one with a locktime in past.
223 2015-12-14 16:55:26 <jl2012> 5
224 2015-12-14 16:56:17 <petertodd> btcdrak: lol, not on purpose :)
225 2015-12-14 16:56:27 <petertodd> btcdrak: just happened to wake up early enough
226 2015-12-14 16:57:10 <jl2012> petertodd: actually, isn't it better to apply the new rules only to UTXO created after the softfork?
227 2015-12-14 16:57:40 <petertodd> jl2012: doing that would be really complex - much easier not too try to do stuff like that
228 2015-12-14 16:58:25 <btcdrak> petertodd: when you get time please can you look at 7184 as a replacement candidate for 6312
229 2015-12-14 16:58:53 <petertodd> btcdrak: sure
230 2015-12-14 16:59:06 <petertodd> btcdrak: though I'm supposed to be on vacation with family for the next week or two :)
231 2015-12-14 16:59:21 <btcdrak> petertodd: the last IRC meeting explains it http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-10-19.01.log.html
232 2015-12-14 16:59:33 <btcdrak> well, if you have time cool :))
233 2015-12-14 16:59:40 <petertodd> btcdrak: thanks
234 2015-12-14 17:00:48 <petertodd> jl2012: bitcoinity is wrong?
235 2015-12-14 17:01:24 <jl2012> there are several bugs on this page https://data.bitcoinity.org/bitcoin/block_version/5y?c=block_version&r=week&t=a
236 2015-12-14 17:02:02 <btcdrak> the punchcard looks OK though?!
237 2015-12-14 17:03:51 <jl2012> btcdrak: actually not. Put you mouse over the blocks on the leftmost column and you will see the numbers do not add up
238 2015-12-14 17:04:37 <instagibbs> maybe mixing my metaphors here
239 2015-12-14 17:04:44 <instagibbs> err, wrong window, thanks history
240 2015-12-14 17:04:56 <jl2012> 4
241 2015-12-14 17:05:33 <btcdrak> it's amazing to see how much lag there is between different nodes receiving the same block.
242 2015-12-14 17:05:35 <petertodd> incidentally, it'd be good if people took a final look at https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki before we finalize it
243 2015-12-14 17:05:47 <petertodd> I'm having my mom check if for spelling/grammar :)
244 2015-12-14 17:06:56 <btcdrak> that makes your mom a contributor to Bitcoin!
245 2015-12-14 17:08:31 <jl2012> 3
246 2015-12-14 17:08:44 <petertodd> btcdrak: lol, I'd have her make a git commit for that, but I won't because privacy :)
247 2015-12-14 17:08:58 <btcdrak> heh
248 2015-12-14 17:09:14 <jouke> v4 enforcement atm? :)
249 2015-12-14 17:09:15 <petertodd> btcdrak: (in general I've told all my non-bitcoin family/friends to think carefully before linking their identity to mine publicly in any way)
250 2015-12-14 17:17:00 <jl2012> 2
251 2015-12-14 17:17:44 <jl2012> 1
252 2015-12-14 17:18:07 <jl2012> the last chance for v3
253 2015-12-14 17:18:38 <btcdrak> ....and a 60min block.....
254 2015-12-14 17:19:14 <jl2012> btcdrak: it's 1am here......
255 2015-12-14 17:19:38 <jl2012> done?
256 2015-12-14 17:19:45 <btcdrak> heh.... you cant miss this :)
257 2015-12-14 17:19:52 <jl2012> happy forking!
258 2015-12-14 17:19:59 <btcdrak> HODL! Enforcement at block #387380 \o/
259 2015-12-14 17:20:31 <petertodd> W00T!
260 2015-12-14 17:20:38 <jonasschnelli> Nice!
261 2015-12-14 17:20:55 <jonasschnelli> Nice height number.
262 2015-12-14 17:20:56 <Lightsword> yay
263 2015-12-14 17:21:15 <jl2012> Thanks petertodd and gmaxwell for your great idea
264 2015-12-14 17:21:30 <btcdrak> yup!!
265 2015-12-14 17:21:54 <harding> Yes, thank you everyone for working on it.
266 2015-12-14 17:21:59 <roasbeef> \o/
267 2015-12-14 17:22:02 <jl2012> This is the first real funtion since Satoshi created Bitcoin 6 years ago
268 2015-12-14 17:22:13 <jl2012> real *new* function
269 2015-12-14 17:22:36 <jl2012> enabling something that was not possible before
270 2015-12-14 17:23:34 <arioBarzan_> would someone post github's link to its implementation please
271 2015-12-14 17:24:53 <btcdrak> mistake #388380
272 2015-12-14 17:26:28 <btcdrak> arioBarzan_: the specification is here https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki, the implementation is https://github.com/bitcoin/bitcoin/pull/6124 (minus the softfork code which came in https://github.com/bitcoin/bitcoin/pull/6351)
273 2015-12-14 17:26:48 <arioBarzan_> btcdrak: thanks
274 2015-12-14 17:29:51 <petertodd> I wonder how long until someone makes a slick cltv-using hodl wallet? https://github.com/petertodd/checklocktimeverify-demos/blob/master/hodl.py works, but isn't exactly user friendly...
275 2015-12-14 17:30:07 <jl2012> See what will happen when a v3 block comes. I'm sure some people is still mining v3
276 2015-12-14 17:30:36 <petertodd> jl2012: and ~70% of the network will relay v3 blocks right now
277 2015-12-14 17:31:07 <ploopkazoo> reddit asshats are proclaiming that "It's time to fork MaxwellCoin". is this related to the transaction fee patch?
278 2015-12-14 17:31:29 <petertodd> ploopkazoo: it's related to reddit trolls
279 2015-12-14 17:31:37 <ploopkazoo> today in particular, I mean
280 2015-12-14 17:31:52 <ploopkazoo> they haven't been this pissed off about anything since block size limit
281 2015-12-14 17:37:26 <Quent> ploopkazoo, they up in arms due to what they perceive to be an illegitimate and unprincipled usurpation of Satoshi's scalability projections to visa levels. No one consulted gmax's or todd's opinion on scalability when they decided to invest, but they read Satoshi's passionate defences and projections
282 2015-12-14 17:37:45 <Quent> I can't blame them, and form a principled analysis I don't see how you can argue with it
283 2015-12-14 17:40:59 <jl2012> Quent: I don't aware Satoshi said anything related to VISA
284 2015-12-14 17:41:37 <instagibbs> #bitcoin-satoshis-vision
285 2015-12-14 17:42:17 <Quent> https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html
286 2015-12-14 17:42:33 <Quent> it's not a vision thing, it's a principles thing
287 2015-12-14 17:43:09 <Quent> if the devs want to turn into a settlement system then as far as principles and legitimacy is concerned they stand on nothing
288 2015-12-14 17:43:11 <instagibbs> it's a non-technical thing, hence off topic
289 2015-12-14 17:43:17 <instagibbs> please take this elsewhere
290 2015-12-14 17:43:22 <arioBarzan_> question: in BIP65
291 2015-12-14 17:43:31 <arioBarzan_> "nLockTime field in transactions themselves is uint32 which only becomes meaningless after the year 2106"
292 2015-12-14 17:43:42 <arioBarzan_> talks about lock-by-blocktime?
293 2015-12-14 17:43:51 <arioBarzan_> or lock-by-blockheight?
294 2015-12-14 17:43:57 <Quent> and in fact can be considered to act in such a way as to amount to outright theft as all who invested in bitcoin did so because of Satoshi's passionate defence of the system and his analytical and logical arguments that it can scale
295 2015-12-14 17:43:58 <afk11> arioBarzan_: You can do block-height, or timestamp
296 2015-12-14 17:44:14 <jl2012> arioBarzan_: the 2106 is blocktime
297 2015-12-14 17:45:57 <Quent> no one considered gmax's opinion that bitcoin can not scale when the decided to invest, so what grants gmax the right to hold out and impose his will? If he thinks bitcoin can not scale then he is welcomed to forkoff if he is truly acting in principled and legitimate manners, rather than hijack Satoshi's coin
298 2015-12-14 17:45:58 <jl2012> with block height it's enough for 9500 years
299 2015-12-14 17:46:32 <Quent> so even if gmax "wins", his victory would be phyric, for he has no leg to stand on...
300 2015-12-14 17:48:14 <jl2012> but a hardfork is needed anyway for the year 2106 overflow
301 2015-12-14 17:49:52 <btcdrak> Quent: great conversation, but it's for #bitcoin. This channel is for protocol discussion.
302 2015-12-14 17:56:36 <Quent> yeah, sorry, I appologise, I was just responding to that guy calling an entire ppls asshats
303 2015-12-14 17:57:09 <Quent> not sure why he didn't get a telling off for that sort of language
304 2015-12-14 17:58:02 <btcdrak> I forgot to tag him
305 2015-12-14 17:58:15 <btcdrak> ploopkazoo: please take it to #bitcoin also
306 2015-12-14 17:59:03 <btcdrak> Quant: but it's not a "telling off". The conversation is fine, just here would be off-topic. #bitcoin is for general discussions
307 2015-12-14 19:09:22 <StephenM347> Looking at https://github.com/bitcoin/bitcoin/pull/7022. Why is tx priority being gotten rid of? I always thought that was a good way of doing it. What will it be replaced with?
308 2015-12-14 19:12:25 <sdaftuar> StephenM347: There was an email thread about this on bitcoin-dev last month: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011713.html
309 2015-12-14 19:12:58 <StephenM347> sdaftuar: I'll give it a read, thanks
310 2015-12-14 19:13:12 <see_not> Soo a dreaded "Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues."
311 2015-12-14 19:13:27 <see_not> Now my wallet is stuck on a certain block, what do
312 2015-12-14 19:14:56 <nwilcox_> Why are there no 0.11.2 release notes in the docs/release-notes directory?
313 2015-12-14 19:15:21 <nwilcox> Also, where can I read about the release process / schedule?
314 2015-12-14 19:15:37 <btcdrak> nwilcox_: you mean this? https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md
315 2015-12-14 19:16:11 <btcdrak> nwilcox_: this is the release process: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md
316 2015-12-14 19:16:19 <sipa> nwilcox: because 0.11 is a separate branch from master... at some point the notes from other branches usually get eh... "forwardported"
317 2015-12-14 19:16:49 <nwilcox> btcdrak: Thanks!
318 2015-12-14 19:17:12 <nwilcox> So is release-notes.md for the latest release, and all older ones appear in the release-notes directory?
319 2015-12-14 19:17:26 <sipa> within each branch, yes
320 2015-12-14 19:17:47 <nwilcox> sipa: I also looked at the release-notes directory within v0.11.2 tag.
321 2015-12-14 19:17:48 <nwilcox> Ok.
322 2015-12-14 19:17:49 <btcdrak> nwilcox: the release process is once tagged, developers (or anyone) fires up their gitian builders and signs the output. If enough agree, the tag becomes the release.
323 2015-12-14 19:21:02 <btcdrak> nwilcox: As for schedule, wumpus posts these to the ML. I believe it was 0.12 feature freeze ~1-Dec, RC phase begins Jan 6th. I think the aim is for a major release every 6 months or so. maintenance releases come as necessary.
324 2015-12-14 19:21:34 <nwilcox> Gotcha.
325 2015-12-14 19:21:58 <nwilcox> Do PRs need to update ./doc/release-notes.md in-band, or is that document updated later?
326 2015-12-14 19:22:27 <nwilcox> (Can I look at 0.12 version of release-notes.md to have a fairly good idea of what that release entails?)
327 2015-12-14 19:22:59 <btcdrak> nwilcox: you should probably read this also https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
328 2015-12-14 19:23:16 <btcdrak> nwilcox: everything is done by PR.
329 2015-12-14 19:23:16 <nwilcox> ok.
330 2015-12-14 19:23:24 <sipa> nwilcox: not everything is included... as pre release the release-notes.md document is really only updated by individual PRs when the author remembers that writing something about it may be useful
331 2015-12-14 19:37:32 <btcdrak> sipa: the softfork seems to have gone well so far... fingers crossed
332 2015-12-14 19:38:02 <sipa> yay
333 2015-12-14 19:38:14 <btcdrak> not seeing any forks...
334 2015-12-14 19:38:44 <btcdrak> but then again, noone has produced a v3 block yet.
335 2015-12-14 19:47:49 <Quent> there seem to be some complaints of nodes malfunctioning
336 2015-12-14 19:57:42 <see_not> Is pieter wuille here?
337 2015-12-14 19:58:26 <sipa> see_not: yes
338 2015-12-14 19:58:59 <see_not> Great! you're the one who saved me multiple times
339 2015-12-14 19:59:41 <see_not> I found your answer on stackoverflow regarding copying over the contents of .bitcoin folder from one machine to another
340 2015-12-14 20:00:16 <see_not> My nodes run 0.95 and one of them reports Warning: The network does not appear to fully agree! Some miners appear to be experiencing issues.
341 2015-12-14 20:00:31 <see_not> and is stuck on block 388366
342 2015-12-14 20:01:00 <see_not> Will copying over the last few files from a machine work? I tried just deleting last blockxx.dat but asked me for a reindex
343 2015-12-14 20:01:29 <gmaxwell> 0.95 is not a bitcoin core version number.
344 2015-12-14 20:01:36 <see_not> 90500
345 2015-12-14 20:01:42 <sipa> 0.9.5 is pretty old
346 2015-12-14 20:01:52 <gmaxwell> Deleting or copying just single files is like giving your node a lobotomy. It will not make it healthy.
347 2015-12-14 20:02:06 <see_not> I know that but upgrading will require a few days...
348 2015-12-14 20:02:47 <sipa> you can copy the full chainstate, or the full blocks/ contents
349 2015-12-14 20:03:06 <sipa> the blocks/ contents cannot be older than the chainstate/ contents
350 2015-12-14 20:03:15 <sipa> (as the chainstate refers to blocks, but not the other way around)
351 2015-12-14 20:03:26 <see_not> I have tens of full nodes spread all over the world some with bad connections
352 2015-12-14 20:03:44 <sipa> i very strongly suggest you to upgrade to at least 0.10
353 2015-12-14 20:04:01 <see_not> Ah I see, well chainstate has about 1.2gb and I thought if copying just that + the latest few blk files would help
354 2015-12-14 20:04:12 <sipa> no
355 2015-12-14 20:04:18 <sipa> you need to copy the entire contents
356 2015-12-14 20:04:24 <gmaxwell> upgrading wouldn't have taken any time-- unless you're referring to local modifications-- if you'd done it while the system weren't corrupted, but in any case you can upgrade and reindex.
357 2015-12-14 20:04:36 <sipa> (especially the block/index/ contents must be up to date)
358 2015-12-14 20:04:46 <see_not> damn might as well upgrade
359 2015-12-14 20:05:23 <gmaxwell> there are numerious security problems with 0.9.5 (not to mention performance)
360 2015-12-14 20:05:24 <see_not> Thanks for the help, I'll consider updating. Maybe its the fact that I run them with txindex too
361 2015-12-14 20:05:27 <sipa> if you're not using the nodes for wallets or mining, you may want to consider trying the 0.12 branch, which is many times faster
362 2015-12-14 20:05:41 <sipa> there is no 0.12 release though, so at your own risk
363 2015-12-14 20:05:43 <gmaxwell> Why are yourunning tens of nodes, in any case?
364 2015-12-14 20:06:18 <see_not> I have 0.12 in testing already on one of my local machines, I could see memory usage is definitely great compared to current
365 2015-12-14 20:06:51 <sipa> cool; feel free to report any issues
366 2015-12-14 20:07:02 <see_not> But either way it will be just a binary update when release is available unlike now where a reindex is a must...
367 2015-12-14 20:07:07 <see_not> Will do if I notice any :)
368 2015-12-14 20:07:44 <sipa> you can't downgrade from 0.10 back to 0.9, or from 0.11 to 0.10 if you enable pruning
369 2015-12-14 20:07:53 <sipa> but forward upgrading shouldn't require a reindex
370 2015-12-14 20:08:10 <gmaxwell> though he needs a reindex now because his state is now corrupt.
371 2015-12-14 20:08:25 <sipa> indeed
372 2015-12-14 20:09:01 <gmaxwell> I suggest just updating to 0.11.2 (or 0.12-pre as sipa suggests, if you aren't depending on these nodes); and then do your reindex.
373 2015-12-14 20:09:18 <gmaxwell> 0.12 branch will reindex like infinity fold faster too. :)
374 2015-12-14 20:10:50 <see_not> Sounds great, I'll upgrade this one where reindex is necessary and wait for a 0.12 release for the rest, I kinda need them operational
375 2015-12-14 20:11:19 <Quent> what you using them for see_not ?
376 2015-12-14 20:12:13 <gmaxwell> if you want to keep them operational you really should upgrade them. As sipa said, no reindex is required.
377 2015-12-14 20:13:06 <Quent> sounds like he is trying to minimise risk, i.e. if one upgrade has a bug etc the other node works, unless I'm mistaken
378 2015-12-14 20:47:03 <puchu> hi
379 2015-12-14 20:47:44 <puchu> i'd like to "play" with the blockchain and build some visualisation tools. is there some library/code to recommend? i would pefer c++/Qt
380 2015-12-14 20:49:17 <puchu> i know there is the bitocin source but i mean some more simplified :)
381 2015-12-14 20:49:49 <puchu> or which part of the source is to recommend the read from the bitcoin sourcecode when i just like to parse the blockchain?
382 2015-12-14 20:57:17 <rusty> kanzure, btcdrak: well, it seems the gentle approach to moderation has failed.  Does someone else want to moderate  jl2012's rant?
383 2015-12-14 21:00:16 <rusty> jl2012: around?
384 2015-12-14 21:06:17 <kanzure> rusty: we should try to bribe and entice jl2012 into contributing more often
385 2015-12-14 21:07:30 <see_not> sipa and gmaxwell : Thank you for all your help tonight & contribution in general to this project, you're great people for still being here and helping out when you could be making tons of $ on consulting etc.
386 2015-12-14 21:07:39 <rusty> kanzure: oh, I loved his proposal.  But I hate that the discussion since has been almost 100% "but you can't steal people's money" followed by <re-explanation of what proposal is>.  There are two more in the queue, from xor.
387 2015-12-14 21:10:19 <gmaxwell> rusty: then why are you blaming jl2012, who has been one of the communities longest sources of interesting thoughts? rather than the walls of pseudonyms that have afaict done nothing and just don't understand the idea?
388 2015-12-14 21:11:52 <kanzure> rusty says one of the jl2012 emails was low-signal or a rehash or something. this might even be true, but confuses issue on moderation policy (unset the moderation bit, or not?), and unfortunately has made jl2012 unfond of the mailing list now (there's a pending email that is :-/).
389 2015-12-14 21:12:20 <kanzure> mostly this is my mistake for not unsetting the moderation bit sooner..... as per policy.
390 2015-12-14 21:12:24 <rusty> gmaxwell: I'm sorry if you read that from what I wrote?   I'm re-reading it now, I thought it was pretty clear that I wasn't criticising him.
391 2015-12-14 21:13:26 <AdrianG> who is jl2012
392 2015-12-14 21:13:42 <sipa> jl2012: who are you?
393 2015-12-14 21:13:44 <kanzure> that is irrelevant
394 2015-12-14 21:13:50 <kanzure> i'm sure he's wonderful, whoever he is :-)
395 2015-12-14 21:13:58 <sipa> AdrianG: might as well ask the guy himself :)
396 2015-12-14 21:20:43 <rusty> kanzure: Your characterization was a bit unfair.  I approved everything, and sent the various participants of the thread a direct email, pointing out that the thread was "starting to go in circles".  Making forward progress was jgarzik's main criterion for moderation.
397 2015-12-14 21:21:35 <kanzure> ah, didn't know you had approved everything, my mistake.
398 2015-12-14 21:21:47 <kanzure> sorta confused about jl2012's pending email then
399 2015-12-14 21:22:29 <rusty> kanzure: hey, it's 7am here, I was surprised it hadn't already been dealt with.  When I get up and there are mails in the mod queue it usually means they're contentious.
400 2015-12-14 21:23:00 <kanzure> no it means i'm punting
401 2015-12-14 21:23:13 <rusty> kanzure: FYI, I'm going to politely bounce xor's emails, and point him to the previous clarification.  Otherwise gmaxwell and jl2012 will feel obligated to respond (again).
402 2015-12-14 21:30:19 <rusty> kanzure: same thing.  I've left jl2012's mail in the queue for now: clearly I've mishandled this, and I'd like the opportunity to contain the damage :(