1 2015-06-22 00:22:36 <petertodd> michagogo: yes I did, which oddly didn't provide the assert files
  2 2015-06-22 02:09:25 <Newyorkadam> hi, i’m working with pybitcointools and I’m getting an error I don’t really understand: “Exception: An outpoint is already spent in [91194964]”
  3 2015-06-22 02:09:50 <Newyorkadam> this is happening after I try to send a tx with the same amount of btc from the same address to the same address more than once
  4 2015-06-22 02:10:10 <Newyorkadam> (to clarify, I’m sending, say, 1 btc from A to B, but twice)
  5 2015-06-22 02:11:39 <eennaam> arent you answering your own question?
  6 2015-06-22 02:12:55 <Newyorkadam> eennaam: what does the error mean?
  7 2015-06-22 02:13:22 <Newyorkadam> like I think I get the idea of it
  8 2015-06-22 02:13:23 <eennaam> Newyorkadam: that you cant double spend?
  9 2015-06-22 02:13:38 <eennaam> you can't spend the same btc two times
 10 2015-06-22 02:13:42 <Newyorkadam> I know
 11 2015-06-22 02:13:49 <eennaam> ok nvm
 12 2015-06-22 02:14:15 <Newyorkadam> but the address I’m trying to spend from has, say, 10 btc in it
 13 2015-06-22 02:14:16 <Newyorkadam> so if it can’t spend the 1btc it already spent, why can’t it spend another 1btc
 14 2015-06-22 02:15:10 <Newyorkadam> oh nvm, I found out why
 15 2015-06-22 02:15:11 <eennaam> i read it incorrectly sorry , i thought the same bitcoin, but you said same amount
 16 2015-06-22 02:15:21 <Newyorkadam> I kept sending with index 0 instead of incrementing it
 17 2015-06-22 02:25:41 <maaku> petertodd: do you see the use case of a CHECKSEQUENCEVERIFY + malleability fix?
 18 2015-06-22 02:26:34 <petertodd> maaku: off the top of my head, to be honest I don't, but I certainly see how it could make technical sense if you needed a series of two unconfirmed txs with that kind of timing (which I think lightning needed?)
 19 2015-06-22 02:27:45 <maaku> right, this is one of the consensus changes needed by lightning (relative-CLTV, which sequencenumbers + checksequenceverify is)
 20 2015-06-22 02:28:01 <petertodd> maaku: it's certainly a *nice* idea, and my proposal of just using nLockTime an ugly hack in some ways, but if it gets 99% of the functionality possible right now I'd be inclined to hold off until more functionality is possible
 21 2015-06-22 02:28:44 <maaku> it is however never the case that we can push through a lot of changes to bitcoin consensus rules at once. Ineeed, it shoudn't be the case.
 22 2015-06-22 02:28:46 <petertodd> maaku: yeah, which is fine, but might as well propose that whole thing as a "package deal" so we can evaluate the entire concept at once - maybe lightning needs a different design?
 23 2015-06-22 02:29:32 <maaku> Baby steps. First get consensus this is a design that works and we want to work towards, and get it in as a policy rule, then get review of CHECKSEQUENCEVERIFY, and then design a more permanent malleability fix
 24 2015-06-22 02:29:43 <petertodd> maaku: well it depends. every soft-fork has some risk, so if the total package of code changes is still reviewable, the overall risk may be less to just do it in one go rather than two, hard to say
 25 2015-06-22 02:30:23 <petertodd> at minimum, without having the rest of the design, I have to evaluate that pull-req on soley its own merits, which currently is limited
 26 2015-06-22 02:30:25 <maaku> petertodd: well CHECKSEQUENCEVERIFY will have slightly better semantics for some use cases than CHECKLOCKTIMEVERIFY
 27 2015-06-22 02:30:50 <petertodd> maaku: I'm sure it will! but we need clear examples, with code, of those semantics to be able to come to consensus that's true
 28 2015-06-22 02:30:56 <maaku> for example, escrow: put a payment in escrow until N blocks after it hits the chain, meaning the clock doesn't start until it receives a confirmation
 29 2015-06-22 02:31:31 <maaku> but I don't want to put that in BIP 68. Let's evaluate the features individually, while being upfront in discussion about where these are going.
 30 2015-06-22 02:31:33 <petertodd> maaku: agreed, but without a tx malleability fix you can't do that now safely
 31 2015-06-22 02:32:06 <maaku> The escrow thing? It doesn't need malleability. I'm talking about a relative-CLTV delayed ability to spend by the recipient
 32 2015-06-22 02:32:16 <PRab_> O
 33 2015-06-22 02:32:21 <petertodd> maaku: exactly my point! without the rest of the design my evaluation of BIP68 is that it's a solution looking for a problem - again, I know this isn't true in the bigger context of things, but we need that context to evaluate it
 34 2015-06-22 02:32:41 <petertodd> maaku: right - it does need CHECKSEQUENCEVERIFY, so again, where's the CHECKSEQUENCEVERIFY BIP? :)
 35 2015-06-22 02:32:57 <maaku> petertodd: I'm working on it, but in series
 36 2015-06-22 02:33:23 <petertodd> maaku: that's fine... but I hope you see my rational for NACKing until it's available
 37 2015-06-22 02:33:31 <PRab_> I'm going to need to rotate my GPG key soon. Anything special I should do because I'm using it for gitian?
 38 2015-06-22 02:33:32 <maaku> I don't
 39 2015-06-22 02:33:41 <maaku> I seriously am just as confused now about it.
 40 2015-06-22 02:34:06 <petertodd> maaku: note the similar situation where I said repeatedly that without at least some example code for CLTV, I'd NACK my own proposal - so of course I wrote it up. Not great, but at least it was a fully fleshed out example.
 41 2015-06-22 02:35:00 <maaku> You know where this is going, the feature is is explained quite simply. Even if it at this time only seems to enable things that you can emulate with nLockTime, we know we're heading in a direction where we want this capability
 42 2015-06-22 02:35:59 <maaku> If you need three changes to get something meaningful done, changes A, B, and C, I don't understand the holdup of refusing to make progress on A because B and C are not ready.
 43 2015-06-22 02:36:26 <petertodd> maaku: look, I'm sorry, but without the full picture I simply do not think you can say that - remember the question is do we merge code into Bitcoin Core based on a design that isn't done yet, where that code isn't useful without the rest of that design
 44 2015-06-22 02:36:40 <maaku> And also, I don't think it makes things clearer to require the explanation of A to depend on B and C -- now it's much more complex and harder to review
 45 2015-06-22 02:37:06 <petertodd> maaku: what happens if you get to part C and realise "ah shoot, part A was definitely done wrong" - we're left with a part A that doesn't have any compelling advantages over the existing system, so we've just added soft-forked-in code complexity
 46 2015-06-22 02:37:52 <maaku> petertodd: go read the lightning docs. it's used there and works. or go read how the peg works in elements alpha. CHECKSEQUENCEVERIFY is used there and works in production
 47 2015-06-22 02:38:16 <maaku> but I don't want to pollute BIP 68 with examples that require an equal amount of text to provide background for
 48 2015-06-22 02:38:35 <gmaxwell> maaku: I think all petertodd is saying is that without the whole vision of it he doesn't see a reason to move it forward?
 49 2015-06-22 02:38:51 <gmaxwell> it doesn't have to be in the same document, I think?
 50 2015-06-22 02:38:57 <petertodd> maaku: I'm not asking you too, I'm just saying that until BIP xx for CHECKSEQUENCEVERIFY is available, I can't as a non-Elements-dev say BIP68 should move forward
 51 2015-06-22 02:39:14 <petertodd> maaku: if you want to stage actual deployment, sure, but lets have a fleshed out plan first
 52 2015-06-22 02:39:36 <gmaxwell> e.g. if X isn't useful without Y, then we want to think about them jointly to make sure we don't end up with an X thats useless because the demands of Y turned out to be different.
 53 2015-06-22 02:40:32 <gmaxwell> which from a general principle sounds not unreasonable.
 54 2015-06-22 02:41:02 <gmaxwell> maybe not always necessary, I dunno if it would be here, but PT thinks so and it's his right to have his own opinion there.
 55 2015-06-22 02:42:47 <petertodd> gmaxwell: frankly part of why I've been a bit cagey about saying what exactly I thought was missing from nSequence was I was hoping someone else would notice that it's not useful on its own - that no-one piped up worries me a little bit about how well people understand it
 56 2015-06-22 02:43:09 <maaku> petertodd: maybe because being useful on its own is not a requirement
 57 2015-06-22 02:43:35 <maaku> it completely baffles me that is a hard requirement for moving forward, that every single change must introduce something which provides a uniqely new capability
 58 2015-06-22 02:44:06 <petertodd> maaku: I'm not arguing that, I'm just arguing that if that isn't true, the dev community should understand why it's still a good diea - without the other details they won't
 59 2015-06-22 02:44:37 <maaku> gmaxwell: I'm responding to his NACK, first on the mailing list and now on github to BIP 68 until there is a clear use case it enables which is not presently possible (e.g. with nLockTime)
 60 2015-06-22 02:45:00 <petertodd> maaku: keep in mind the fact that the argument why it's a good change is coming from Elements is bad politics, as it risks giving the (wrong) impression that blockstream devs are getting a pass here
 61 2015-06-22 02:45:10 <maaku> and there isn't except for single-party signature replacement, which I don't think any protocols use, or at least I'm not familiar with them
 62 2015-06-22 02:45:52 <maaku> petertodd: so I can't point to the only place it's used in production?
 63 2015-06-22 02:45:54 <maaku> what the fuck
 64 2015-06-22 02:47:31 <petertodd> maaku: of course you can... but you haven't actually done that on the pull-req or in the BIP
 65 2015-06-22 02:47:57 <eennaam> (he left)
 66 2015-06-22 02:48:31 <gmaxwell> petertodd: I'll talk to him, as you know things are stressful for everyone right now.
 67 2015-06-22 02:49:33 <petertodd> gmaxwell: thanks
 68 2015-06-22 02:50:40 <petertodd> gmaxwell: to be clear, I think it's a reasonable proposal, but we really need to be careful about appearing to cut corners with consensus building if we're going to keep our moral legitimacy
 69 2015-06-22 04:26:54 <michagogo> petertodd: o_O
 70 2015-06-22 04:27:24 <michagogo> Exact same commands as for Linux, except for the yml? No errors?
 71 2015-06-22 04:27:44 <petertodd> michagogo: that's what I remember, could be mistaken
 72 2015-06-22 04:28:07 <michagogo> petertodd: got shell history?
 73 2015-06-22 04:28:21 <petertodd> michagogo: nah sorry
 74 2015-06-22 04:29:04 <petertodd> michagogo: specifically i ran this command: ./bin/gbuild --commit bitcoin=v${VERSION} ../bitcoin/contrib/gitian-descriptors/gitian-win.yml
 75 2015-06-22 04:29:09 <petertodd> michagogo: from https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md
 76 2015-06-22 04:29:17 <petertodd> michagogo: and didn't get any assert files for windows
 77 2015-06-22 04:29:31 <petertodd> michagogo: don't have the output from gitian itself though; turned off that VM
 78 2015-06-22 04:33:45 <michagogo> Newyorkadam: addresses don't have balances
 79 2015-06-22 04:33:50 <michagogo> petertodd: that command builds
 80 2015-06-22 04:33:56 <michagogo> gsign needs to be run next
 81 2015-06-22 04:34:07 <michagogo> That signs and puts the asserts in the right place
 82 2015-06-22 04:34:30 <michagogo> Assert and sig+
 83 2015-06-22 04:34:32 <petertodd> michagogo: haha, how did i screw that up yet get the linux ones right? that's exactly what I did wrong :(
 84 2015-06-22 04:34:37 <michagogo> sig**
 85 2015-06-22 04:34:50 <petertodd> michagogo: oh well, the lack of windows sigs from me can be my forever shame :)
 86 2015-06-22 04:34:55 <michagogo> petertodd: if you haven't run gbuild or deleted files, you can still sign
 87 2015-06-22 04:35:05 <michagogo> The outputs will still be there
 88 2015-06-22 04:35:13 <petertodd> michagogo: yeah, I'll get around to that later
 89 2015-06-22 04:35:47 <michagogo> I have a script that does the whole build (all 4 sigs) at
 90 2015-06-22 04:35:50 <michagogo> automatically
 91 2015-06-22 04:36:07 <michagogo> And automatically skips the OS X sig if it's not yet available
 92 2015-06-22 04:37:23 <michagogo> (Though I need to fix something for the latest OS X changes)
 93 2015-06-22 04:38:06 <petertodd> michagogo: yeah, no OS X here
 94 2015-06-22 04:48:09 <michagogo> Having that script is nice -- only used it a couple times, but it prevents that kind of mistake
 95 2015-06-22 04:48:23 <michagogo> I even set it up to auto-commit+push+PR
 96 2015-06-22 04:51:41 <jonasschnelli> How would it be possible to generate a Bip65 softfork chart (if it gets merged)?
 97 2015-06-22 04:53:54 <petertodd> jonasschnelli: http://bitcoin.sipa.be/ver-2k.png
 98 2015-06-22 04:54:58 <jonasschnelli> petertodd: but as I read you PR code I can't see a blockversion increasing.
 99 2015-06-22 04:55:20 <petertodd> jonasschnelli: yeah, we haven't decided on an exact deployment plan
100 2015-06-22 04:56:06 <jonasschnelli> petertodd: okay. I'll see. There would be space for more softfork stuff.
101 2015-06-22 05:00:41 <jonasschnelli> michagogo: cool. We should share our gitianscripts. I'm also using the same script for autobuilding PRs, etc.: https://builds.jonasschnelli.ch
102 2015-06-22 05:02:15 <jonasschnelli> You should also do nightly builds at UTC0. This would allow signature comparison.
103 2015-06-22 05:05:34 <fanquake> jonasschnelli is your script available somewhere?
104 2015-06-22 05:10:19 <jonasschnelli> fanquake: no. Not at the moment. Needs cleanup first. Also it's a bit customized for my environment.
105 2015-06-22 06:41:32 <Alit> Can't wait for the stress-test to begin in couple hours..
106 2015-06-22 06:54:45 <CodeShark> who is doing a stress test?
107 2015-06-22 06:55:41 <gmaxwell> some super sketchy "exchange" which is run by completely anonymous parties and was created a couple weeks ago; looks like they're doing some event as a stunt to get a bunch of traffic to their site (and presumably deposits), I'm guessing you won't take the opposite side of a bet with me on what happens next? :P
108 2015-06-22 06:56:16 <CodeShark> lol
109 2015-06-22 06:59:36 <CodeShark> are these the same people who did a similar stunt a few days ago?
110 2015-06-22 07:00:08 <jonasschnelli> Oh. Why is the nLockTime 32bit? bitcoin should live longer then 2038!
111 2015-06-22 07:00:37 <CodeShark> lol - 32 bit datatypes will be totally obsolete by then :p
112 2015-06-22 07:01:11 <gmaxwell> CodeShark: they seem to be claiming so; though their account on reddit was created after and their initial posts are speaking about that 'test' in the third person as though they weren't.
113 2015-06-22 07:01:19 <Alit> gmaxwell those are some serious accusations, you better stop right there.
114 2015-06-22 07:01:56 <CodeShark> or else?
115 2015-06-22 07:02:22 <Luke-Jr> Alit: please don't attack Bitcoin. stress-test is something you do on testnet.
116 2015-06-22 07:02:32 <Alit> ...I kick his dog
117 2015-06-22 07:03:13 <Alit> bitcoin needs to be attack-proof
118 2015-06-22 07:03:29 <Alit> perfect time to drop it to its knees now, before going mainstream
119 2015-06-22 07:03:57 <Luke-Jr> Alit: well, that's why we have a 1 MB block limit, so the attacks can't do as much damage. can you imagine if they were able to inflate to 8 MB blocks? anyhow, #bitcoin for this topic
120 2015-06-22 07:04:21 <gmaxwell> Luke-Jr: thanks for the redirect.
121 2015-06-22 07:15:13 <wumpus> does anyone happen to have a copy of http://sourceforge.net/projects/bitcoin/files/Bitcoin/blockchain/Mar12Fork.dat/download as mentioned in checkblock_tests.cpp
122 2015-06-22 07:34:58 <jonasschnelli> i'm a script greenhorn. Can't i just to <OP_DUP> <OP_HASH160> <hash> OP_EQUALVERIFY <int32> <OP_CHECKLOCKTIMEVERIFY>?
123 2015-06-22 07:35:13 <jonasschnelli> *just do
124 2015-06-22 07:50:19 <jonasschnelli> got it, missed the "04" before the <int32>
125 2015-06-22 07:50:40 <Luke-Jr> jonasschnelli: you know that won't be a valid send-to-address, right?
126 2015-06-22 07:51:24 <Luke-Jr> ie, you don't want to expose it to the user as "send to address, with a lock time"
127 2015-06-22 07:51:26 <jonasschnelli> Luke-Jr: why? do i need a OP_IF/OP_ELSE?
128 2015-06-22 07:51:43 <Luke-Jr> jonasschnelli: no, because the address specifies the entire script to be used.
129 2015-06-22 07:51:53 <Luke-Jr> if you add or change it in any way, it is no longer valid for the address
130 2015-06-22 07:52:32 <Luke-Jr> ie, if I ask you to pay 1someaddress, and you append a locktime like that, you're basically just burning bitcoins
131 2015-06-22 07:54:34 <CodeShark> wouldn't you want to do the OP_CHECKLOCKTIMEVERIFY in the redeemscript?
132 2015-06-22 07:55:46 <jonasschnelli> Luke-Jr: okay. I see. It was a dump example. My goal is to create a OP_IF HASH160 <hash> OP_ EQUALVERIFY <pkeyA> OP_CHECKSIG OP_ELSE <int32> OP_ CHECKLOCKTIMEVERIFY OP_DROP <pkeyB> OP_CHECKSIG OP_ENDIF
133 2015-06-22 07:55:48 <CodeShark> the signature is not part of the script :p
134 2015-06-22 07:56:01 <CodeShark> (well, it is but it really isn't)
135 2015-06-22 07:57:07 <phantomcircuit> CodeShark, the script in the output is a signature
136 2015-06-22 07:57:22 <phantomcircuit> im thinking there's some confusion about terminology here...
137 2015-06-22 07:57:31 <CodeShark> yes, the terminology is very confusing here
138 2015-06-22 07:57:34 <Luke-Jr> CodeShark: there are two scripts in Bitcoin: a pubkey script, and a signature script..
139 2015-06-22 07:58:09 <Luke-Jr> it's pretty straightforward IMO <.<
140 2015-06-22 07:58:17 <Luke-Jr> the signature script has to satisfy the pubkey script
141 2015-06-22 07:58:31 <CodeShark> unless otherwise required, I start by assuming p2sh. assuming p2sh, I think {signatures} {redeemscript} for input script and {redeemscript hash} for txout script
142 2015-06-22 07:58:37 <phantomcircuit> Luke-Jr, it is but only when you say signature script instead of signature :P
143 2015-06-22 07:58:58 <CodeShark> I know that early documents tend to use scriptPubKey and scriptSig
144 2015-06-22 07:59:12 <CodeShark> and abstractly this is still in a sense correct
145 2015-06-22 07:59:21 <wumpus> CodeShark: right, because they're called like that in the source code
146 2015-06-22 07:59:22 <CodeShark> but these terms do NOT refer to ECDSA keys...and it can get confusing
147 2015-06-22 07:59:28 <phantomcircuit> CodeShark, anyways you want the checklocktimeverify in the scriptPubKey
148 2015-06-22 07:59:45 <phantomcircuit> (regardless of whether that's via p2sh or not)
149 2015-06-22 07:59:56 <Luke-Jr> CodeShark: ok, then your comment makes sense; redeemscript is the right place for it
150 2015-06-22 08:00:57 <CodeShark> so to make it absolutely unambiguous that I am not talking about ECDSA priv and pubkeys and their signatures, I prefer to avoid the terms scriptSig and scriptPubKey
151 2015-06-22 08:02:04 <CodeShark> with many of the core developers, these terms are probably the most readily understood - but with just about anyone else it only leads to a confusing mess
152 2015-06-22 08:03:32 <CodeShark> i.e. using the terms input and output script leads to far less confusion
153 2015-06-22 08:04:09 <CodeShark> these terms are more syntactic than semantic - but they are pretty unambiguous
154 2015-06-22 08:04:52 <CodeShark> scriptSig and scriptPubKey are more semantic but are way too abstract
155 2015-06-22 08:05:59 <Luke-Jr> scriptSig & scriptPubKey are just hungarian notation variable names for "signature script" and "pubkey script" :p
156 2015-06-22 08:06:13 <CodeShark> camelCase
157 2015-06-22 08:06:20 <CodeShark> but that's not the point
158 2015-06-22 08:06:34 <CodeShark> they could be script_sig or m_scriptSig or whatever...the point still holds
159 2015-06-22 08:07:20 <CodeShark> the issue isn't really that they are too abstract..but that they operate within too close proximity of ECDSA keys...that have an entirely different meaning
160 2015-06-22 08:07:45 <CodeShark> so I think it's poor naming - but I won't really argue with the source code conventions :p
161 2015-06-22 08:08:27 <CodeShark> point is, I probably wouldn't use the terms "signature script" and "pubkey script" in a user's manual
162 2015-06-22 08:08:59 <wumpus> right
163 2015-06-22 08:09:05 <Luke-Jr> CodeShark: I hope to some day see PGP adopt a similar cryptosystem.
164 2015-06-22 08:09:23 <Luke-Jr> user's manual shouldn't deal with low-level concepts at all
165 2015-06-22 08:09:44 <CodeShark> well, consider a user's manual for a script authoring tool
166 2015-06-22 08:10:26 <Luke-Jr> someone who doesn't get this, shouldn't be writing Scripts
167 2015-06-22 08:10:52 <moa> Luke-Jr: even assembly has technical manuals
168 2015-06-22 08:11:02 <Luke-Jr> ☺
169 2015-06-22 08:14:43 <CodeShark> I would also add that it would be nice to put the signatures in a separate structure that can be populated after-the-fact and that does not get hashed for the purpose of uniquely identifying transactions
170 2015-06-22 08:14:56 <CodeShark> :)
171 2015-06-22 08:15:32 <CodeShark> right now I have to hack around this by using null placeholders and parsing the script
172 2015-06-22 08:15:49 <CodeShark> and having a special "unsigned hash"
173 2015-06-22 08:16:36 <CodeShark> a separate structure that can store indexed items...and an operator to push them onto the script evaluation stack
174 2015-06-22 08:17:16 <CodeShark> rather than assuming this 0 sig1 sig2 ... format
175 2015-06-22 08:18:48 <CodeShark> these items don't even have to be signatures - i.e. they could be the solution to any arbitrary puzzle...
176 2015-06-22 08:19:33 <CodeShark> "compute the factorization of pq for me and collect a bitcoin"
177 2015-06-22 08:21:16 <CodeShark> I guess signatures are also puzzles like this...
178 2015-06-22 08:24:22 <CodeShark> basically, a script should be a program that can take arbitrary input from the redeemer - and if the input satisfies the script, the redeemer gets to transfer the value to an arbitrary script hash
179 2015-06-22 08:24:41 <CodeShark> now we have a fully general scripting model and can build sophisticated protocols atop it
180 2015-06-22 08:25:47 <CodeShark> the input is not hashed when identifying the transaction...but is hashed when computing block merkle roots
181 2015-06-22 08:28:26 <CodeShark> input as in the data that unlocks the script, not as in the value being redeemed :)
182 2015-06-22 08:30:53 <CodeShark> yeah, I know...nothing new here...just dreaming :p
183 2015-06-22 08:39:09 <wumpus> yes we all  dream sometimes :)
184 2015-06-22 08:40:07 <wumpus> btw does anyone know what these "[Transifex] The language Chinese was requested for the project bitcoin of the organization Bitcoin" mails mean? (besides that we already have a Chinese translation)
185 2015-06-22 08:41:44 <michagogo> jonasschnelli: here's what my script looks like atm https://www.irccloud.com/pastebin/3NOV28Ln/
186 2015-06-22 08:43:16 <buZz> perhaps just transifex bug
187 2015-06-22 08:43:32 <Luke-Jr> China is a big place?
188 2015-06-22 08:46:19 <wumpus> Luke-Jr: right, I'm aware that multiple languages are spoken in China
189 2015-06-22 08:46:31 <wumpus> Requested (56) - ehh oops
190 2015-06-22 08:46:33 <sipa> CodeShark: re: signatures in a separate datastructure that isn't hashed into txid: that is what segregated witness in elements alpha does
191 2015-06-22 08:46:43 <CodeShark> yes, I know :)
192 2015-06-22 08:49:17 <CodeShark> take it one level more abstract and just treat it as a satisfaction problem on arbitrary input :)
193 2015-06-22 08:52:56 <CodeShark> lol
194 2015-06-22 08:54:55 <CodeShark> an NP language :p
195 2015-06-22 08:55:30 <CodeShark> O(max p(x), constant)
196 2015-06-22 08:55:33 <CodeShark> err
197 2015-06-22 08:55:40 <CodeShark> O(max[p(x), constant])
198 2015-06-22 08:55:41 <wumpus> #bitcoin-wizards?
199 2015-06-22 08:56:12 <CodeShark> or min[p(x), constant] rather :p
200 2015-06-22 08:56:26 <CodeShark> ok, wizards it is
201 2015-06-22 08:57:30 <wumpus> yes, not trying to be dismissive, but you will likely find more people that actually understand you and discuss these things there :)
202 2015-06-22 09:12:35 <warren> sipa: confirmed both subscribed and unsubscribed users now get the redirect bounce when posting to the old list
203 2015-06-22 09:12:59 <sipa> ok
204 2015-06-22 09:22:32 <bedeho> Does the bitcoin qt wallet keep all keys decrypted in memory at all times, or are they read from disk on a per need basis?
205 2015-06-22 09:22:59 <sipa> they are in memory in encrypted form the whole time
206 2015-06-22 09:23:08 <sipa> and get decrypted when needed
207 2015-06-22 09:28:22 <bedeho> sipa: I see, why doesnt regular OS level security of memory cut it?
208 2015-06-22 09:30:22 <sipa> bedeho: belt and suspenders
209 2015-06-22 09:31:11 <wumpus> it is just a sensible policy, or do you disagree?
210 2015-06-22 09:31:50 <bedeho> wumpus: no not really, I am just trying to understand how it works
211 2015-06-22 09:32:16 <wumpus> e.g. it could be even better, by using OS-level sandboxing and keeping the keys as well as signing in a secure process
212 2015-06-22 09:33:00 <bedeho> so given that the user does not supply the wallet password all the time, where is that kept? wouldnt that also be in memory in cleartext?
213 2015-06-22 09:33:06 <wumpus> but as it is now is as far as possible to go toward protecting private keys without platform specific magic
214 2015-06-22 09:33:29 <sipa> the passphrase is kept in memory as long as necessary
215 2015-06-22 09:33:32 <sipa> then wiped
216 2015-06-22 09:36:18 <bedeho> sipa: so we are getting extra security, despite the password being in memory quite often, because it is some times wiped, at which point the user would have to reenter it. This is better than just having all keys in cleartext memory all the time, is that the idea?
217 2015-06-22 09:37:55 <wumpus> yes; sensitive data such as keys and passphrases is also stored in non-swappable memory, if available
218 2015-06-22 09:38:18 <wumpus> and it is zeroed after use before deallocation
219 2015-06-22 09:39:50 <bedeho> wumpus:ah yes, didnt even think of swapping as an issue.
220 2015-06-22 09:51:11 <wallet42> how can i get libsepc256k1 benchmarks on my processor?
221 2015-06-22 09:52:04 <wumpus> wallet42: ./configure --enable-benchmark && make && ./bench_verify
222 2015-06-22 09:52:16 <wumpus> (and other bench_*)
223 2015-06-22 09:52:25 <wallet42> thhy :)
224 2015-06-22 09:52:42 <wumpus> (so to be clear that's from the secp256k1 root, not from bitcon's)
225 2015-06-22 09:53:23 <wallet42> yes thats the one i was looking for
226 2015-06-22 09:53:39 <wallet42> and i saw bench_verify.c but i didnt find how to compile it
227 2015-06-22 09:53:56 <wallet42> --enable-benchmark is the magic i was looking for
228 2015-06-22 09:55:32 <wallet42> is the benchmark singlecore?
229 2015-06-22 09:57:22 <sipa> yes
230 2015-06-22 10:05:11 <michagogo> wallet42: as a general tip, stuff like that is usually set at configure-time
231 2015-06-22 10:05:27 <michagogo> Which means you can see options like that with ./configure --help
232 2015-06-22 11:19:08 <wumpus> secp256k1 has nothing to handle threads, not in the test framework either; you could approximate a multi-threaded benchmark by launching a bench instance per core
233 2015-06-22 13:24:40 <bedeho> What is the easiest example of a bitcoin wallet one can look at to get an indication about how to do things?
234 2015-06-22 13:25:29 <LeMiner> multibit/electrum?
235 2015-06-22 13:30:04 <wumpus> android wallet?
236 2015-06-22 13:38:00 <bedeho> LeMiner: will have a look
237 2015-06-22 13:38:55 <bedeho> wumpus: no, not an android wallet in particular,just anything which quite clearly reveals how keys and transactions are stored on disk, in memory, and how security is managed.
238 2015-06-22 13:42:33 <wumpus> yes, but I mean aschildbach's wallet could be used as an example
239 2015-06-22 13:43:14 <wumpus> it's straightforward and to the point
240 2015-06-22 13:47:50 <bedeho> wumpus: I see, didnt get you there, this one yeah? https://github.com/schildbach/bitcoin-wallet
241 2015-06-22 13:52:19 <wumpus> yes
242 2015-06-22 13:55:24 <wumpus> there is also 'bitc' which is a straightforward C implementation of a SPV wallet: https://github.com/bit-c/bitc   (not necessarily best practices and hardly reviewed, though)
243 2015-06-22 13:56:04 <jonasschnelli> +1 for bitc (easy to understand, easy to extend)
244 2015-06-22 13:59:13 <bedeho> so in all these cases, whether you use berkelydb or custom protobuf thing like schildbach, do you have to keep dumping everything to disk and encrypting for every little thing that changes?
245 2015-06-22 13:59:47 <bedeho> Like say you are doing a wallet with payment channels, so you need to update stuff a few times a second?
246 2015-06-22 14:00:39 <wumpus> I don't understand that question - you only need to update your store if something changes, e.g. a transaction is sent or received, a new key is generated
247 2015-06-22 14:00:59 <jonasschnelli> bedeho: you only need to encrypt private keys to make sure, nobody can spend you coins if he gets your wallet data
248 2015-06-22 14:01:17 <jonasschnelli> bedeho: if you receive a transaction, no encryption is required.
249 2015-06-22 14:01:42 <jonasschnelli> if you send coins, you need to decrypt your wallet for signing.
250 2015-06-22 14:01:48 <jonasschnelli> as well if you create new addresses
251 2015-06-22 14:01:52 <wumpus> there should certainly be no need to update anything 'a few times per second'
252 2015-06-22 14:02:32 <bedeho> ok, so only private keys in the wallet are encrypted, not the entire wallet?
253 2015-06-22 14:02:43 <jonasschnelli> bedeho: for bitcoin-core; yes
254 2015-06-22 14:02:43 <wumpus> in the case of bitcoin core only private keys are encrypted
255 2015-06-22 14:03:36 <wangchun_> there seems to be a two-block long fork
256 2015-06-22 14:03:37 <wumpus> this makes it possible to e.g. view the balance without typing a passphrase; you need the passphrase only when you send coins, or when you generate a new key and the keypool is exhausted
257 2015-06-22 14:03:42 <jonasschnelli> bedeho: but it could make sense to also encrypt the rest of the wallet
258 2015-06-22 14:03:59 <bedeho> wumpus: ah, makes sense
259 2015-06-22 14:03:59 <wangchun_> f2pool found 362037 000000000000000007643937ad9e070acb3da559083ec5f2f36acdb519f028e0 at 2015-06-22T13:44:09Z
260 2015-06-22 14:04:02 <wumpus> other wallets may make other implementation choices
261 2015-06-22 14:04:06 <sipa> wangchun_: so?
262 2015-06-22 14:04:19 <wangchun_> bitfury found 362037 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 at 2015-06-22T13:44:15
263 2015-06-22 14:04:22 <jonasschnelli> bedeho: i see two "value-levels" of data. First: private keys, Second: metadata.
264 2015-06-22 14:04:39 <wangchun_> btcchina found 362038 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 at 2015-06-22T13:44:52Z
265 2015-06-22 14:04:41 <sipa> one is private, the other is secret
266 2015-06-22 14:04:54 <wangchun_> hmm
267 2015-06-22 14:04:59 <sipa> losing metadata only hurts your privacy, not your money
268 2015-06-22 14:05:10 <wangchun_> btcchina seems have bug in their software..
269 2015-06-22 14:05:30 <jonasschnelli> sipa: agreed. And therefore the 2nd encryption level could keep the key longer in memory (session timeout).
270 2015-06-22 14:06:03 <petertodd> wangchun_: blockchain.info just went down
271 2015-06-22 14:06:20 <leakypat> Bitpay insight fell over earlier too
272 2015-06-22 14:06:28 <bedeho> right, so even in the scenario where you encrypt metadata, you are not really actually encrypting the entire wallet.dat as one thing, you are encrypting individual fields, is that the key? otherwise you would have to dump the whole thing to disk on each change?
273 2015-06-22 14:06:51 <wumpus> yes
274 2015-06-22 14:06:59 <wangchun_> the weird thing is antpool follows btcchina..
275 2015-06-22 14:07:06 <bedeho> leakypat: insight seems extremly unreliable in general
276 2015-06-22 14:07:07 <sipa> "follows" ?
277 2015-06-22 14:07:09 <jonasschnelli> bedeho: append only filestore would make sense in this case
278 2015-06-22 14:07:18 <wangchun_> i think antpool is watching btcchina's stratum header and mining on top it without verify
279 2015-06-22 14:07:42 <sipa> .:(
280 2015-06-22 14:08:14 <jonasschnelli> bedeho: the problems with wallets-stores are, you don't want to write to many data at once to help agains loosing your integrity.
281 2015-06-22 14:08:56 <bedeho> jonasschnelli : how does append only filestores solve the issue I described? is berkelydb append only?
282 2015-06-22 14:09:18 <bedeho> not sure I get exactly what you mean by append only filestore in the context of databases
283 2015-06-22 14:09:19 <jonasschnelli> bedeho: no. Not bdb. Have a look at sipas logdb: https://github.com/bitcoin/bitcoin/pull/5686
284 2015-06-22 14:09:52 <jonasschnelli> It basically adds only records.
285 2015-06-22 14:09:53 <wumpus> berkeleydb is certainly not append-only. Please do your own homework :p
286 2015-06-22 14:10:42 <jonasschnelli> bedeho: we are only talking about key/value store. right. So if you add a record for a already exiting key, then you won't delete the first one.
287 2015-06-22 14:10:53 <jonasschnelli> bedeho: this means your file can only grow,...
288 2015-06-22 14:11:09 <jonasschnelli> You could encrypt every frame/record
289 2015-06-22 14:11:28 <jonasschnelli> but better selective encrypt records.
290 2015-06-22 14:11:34 <jonasschnelli> (only the value)
291 2015-06-22 14:11:38 <bedeho> sure, ok. and lookup gives you last added?
292 2015-06-22 14:11:54 <petertodd> wangchun_: odd, I was just looking at my logs, and 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 didn't show anything abnormal
293 2015-06-22 14:12:00 <jonasschnelli> bedeho: you map everything into mem. Last key/value will last in mem
294 2015-06-22 14:12:24 <bedeho> I see
295 2015-06-22 14:12:55 <jonasschnelli> Normally append only db get read in backward until you find the key, but in our case that's not relevant because we keep everything in mem
296 2015-06-22 14:13:00 <wangchun_> petertodd: yes, but from btcchina and antpool stratum header, at one time, they are mining with previousblockheader = 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 and height = 362038
297 2015-06-22 14:13:20 <wangchun_> previousblockhash
298 2015-06-22 14:13:23 <petertodd> wangchun_: which is fine - they probably just didn't get the other side of the fork yet - the block itself seems to be valid
299 2015-06-22 14:13:37 <wangchun_> petertodd: yes, but they are losing money
300 2015-06-22 14:13:38 <jonasschnelli> bedeho: also mind phantomcircuit's frame fromat: https://github.com/bitcoin/bitcoin/pull/5686#issuecomment-103354054
301 2015-06-22 14:14:12 <petertodd> wangchun_: agreed, but I don't see any reason to think it's anything but a latency issue, possibly caused by the tx flood that's happening right now
302 2015-06-22 14:14:15 <jonasschnelli> (proposal)
303 2015-06-22 14:14:34 <bedeho> jonasschnelli: so why is the append only part needed to avoid having to redumping entire wallet when you make one change? so long as you encrypt each value individually, rather than entire wallet (like I was first thinking), arent you good? is append only acheiving something else?
304 2015-06-22 14:14:49 <wangchun_> petertodd: we are following them too, i must ask them to fix their software, wtf, we'll lose money too
305 2015-06-22 14:15:08 <petertodd> wangchun_: this is the log I saw on my node, grepping just UpdateTip's: http://0bin.net/paste/AW58GYY68CoYTeiR#ZlVin1AMahMtWgnQ7UlL7ZcOCOwbYTyuwuf1-uz7V3I
306 2015-06-22 14:15:51 <jonasschnelli> bedeho: you need a way of redumping the whole thing (mem -> disk). For two reasons: a) kick out old stuff, reduze filesize  b) if you encrypt a unencrypted wallet. Otherwise older records (not deleted) would leak your private key
307 2015-06-22 14:16:34 <jonasschnelli> bedeho: the filestore itself must not be encrypted. Only the values in the key/value store.
308 2015-06-22 14:16:43 <wangchun_> petertodd: it was lucky, bitfury got orphaned?
309 2015-06-22 14:16:56 <petertodd> wangchun_: I'm not sure there is a problem here other than latency - do you have logs from, say, a 0.9.x node? both my 0.10.2 and 0.11.x nodes saw the same fork
310 2015-06-22 14:17:26 <petertodd> wangchun_: possibly! if they had particularly bad latency out, the issue may be that the block you were following on stratum hadn't gotten to enough hashing power
311 2015-06-22 14:18:53 <wangchun_> petertodd: it was our block with wrong height, bitfury was about 5 seconds late than us
312 2015-06-22 14:19:25 <petertodd> wangchun_: what do you mean by "wrong height"?
313 2015-06-22 14:19:40 <wangchun_> no one but btcchina was mining upon their block, but after a while, btcchina changed their block height, so antpool started to follow btcchina
314 2015-06-22 14:20:05 <sipa> petertodd:
315 2015-06-22 14:20:06 <sipa> 16:04:19 < wangchun_> bitfury found 362037 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 at 2015-06-22T13:44:15
316 2015-06-22 14:20:08 <petertodd> changed their block height? sorry, what do you mean by that exactly?
317 2015-06-22 14:20:10 <sipa> 16:04:22 < jonasschnelli> bedeho: i see two "value-levels" of data. First: private keys, Second: metadata.
318 2015-06-22 14:20:13 <sipa> 16:04:39 < wangchun_> btcchina found 362038 00000000000000000cc91f2c852c049c9a63f15db4bf3d231682ead3b5d55309 at 2015-06-22T13:44:52Z
319 2015-06-22 14:20:13 <wangchun_> you need previousblockhash, height, and bits to mine
320 2015-06-22 14:20:23 <sipa> that seems to just be a bug
321 2015-06-22 14:20:32 <jonasschnelli> :)
322 2015-06-22 14:21:18 <petertodd> wangchun_: ah! so stratum reports block height, and your software believed that rather than calculating the height itself?
323 2015-06-22 14:21:41 <wangchun_> petertodd: i am watching them :)
324 2015-06-22 14:21:44 <sipa> i doubt they're calculating anything themselves
325 2015-06-22 14:22:23 <petertodd> that explains the problem then; don't do that :) if you're going to be doing stuff like that you should implement enough SPV logic to validate the block headers at least
326 2015-06-22 14:22:57 <wangchun_> petertodd: i bet antpool is doing the same
327 2015-06-22 14:23:12 <sipa> yay decentralized validation
328 2015-06-22 14:23:54 <petertodd> yeah, we really need to make it impossible to mine on SPV headers...
329 2015-06-22 14:24:19 <petertodd> wangchun_: though I completely agree with you that it makes sense from a business point of view :(
330 2015-06-22 14:24:45 <wangchun_> petertodd: and the good thing is, it makes so called selfish mining impossible
331 2015-06-22 14:25:19 <petertodd> wangchun_: how so?
332 2015-06-22 14:25:29 <sipa> petertodd: take hash of header with nonce set to 0, find utxo entry with txid closest to it, put a commitment to it in the coinbase :)
333 2015-06-22 14:25:34 <wangchun_> while you can delay propagate your block, you cannot delay your miners on stratum
334 2015-06-22 14:26:09 <petertodd> wangchun_: heh, ah, yeah that is true :)
335 2015-06-22 14:26:18 <sipa> that assuming the mining operation and joining the hashing is public
336 2015-06-22 14:26:19 <petertodd> wangchun_: horrible, but true :)
337 2015-06-22 14:26:21 <sipa> but indeed
338 2015-06-22 14:27:17 <petertodd> selfish mining makes some pessimistic assumptions about the fragility of the P2P network - with small blocks and diverse interconnects those assumptions don't hold true
339 2015-06-22 14:31:02 <bedeho> jonasschnelli: thanks the help!
340 2015-06-22 14:37:25 <petertodd> wangchun_: BTW, I wrote up a thing on tx fees mentioning f2pool and fss-rbf: https://gist.github.com/petertodd/8e87c782bdf342ef18fb
341 2015-06-22 14:40:48 <wumpus> petertodd: nice write-up
342 2015-06-22 14:41:04 <petertodd> wumpus: thanks!
343 2015-06-22 14:57:39 <jonasschnelli> mempool 6247871 bytes, 7179tx
344 2015-06-22 14:59:25 <jonasschnelli> estimatefee 1: 0.00198003 :)
345 2015-06-22 14:59:25 <petertodd> jonasschnelli: these coinwallet guys may have decided to set a "floor" minfee value and ahve been releasing just enough txs to outcompete anything under that floor
346 2015-06-22 15:01:36 <wumpus> "size" : 6595, "bytes" : 5711969 here
347 2015-06-22 15:01:53 <jonasschnelli> same here now
348 2015-06-22 15:01:55 <jonasschnelli> ~
349 2015-06-22 15:02:23 <jonasschnelli> the run out of fuel
350 2015-06-22 15:02:26 <jonasschnelli> they
351 2015-06-22 15:02:49 <wumpus> miners must love them
352 2015-06-22 15:03:14 <petertodd> wumpus: +1
353 2015-06-22 15:03:21 <jonasschnelli> Ha!
354 2015-06-22 15:03:32 <jonasschnelli> 6-10 blocks and it's over..
355 2015-06-22 15:03:45 <jonasschnelli> like new-years eve for sms providers.
356 2015-06-22 15:10:27 <jonasschnelli> estimatefee 1: 0.00221238 (at the moment writing to the blockchain is expansive)
357 2015-06-22 15:21:25 <leakypat> 53 cents, punchy
358 2015-06-22 15:26:12 <wumpus> that's if you want it mined the next block, "estimatefee 2" is 0.00012514 (the default) here
359 2015-06-22 15:27:05 <wumpus> (default nTxConfirmTarget is 2 as of #6126)
360 2015-06-22 15:32:54 <morcos> jonasschnelli: was your estimate from a master/0.11 node or a 0.10 node
361 2015-06-22 15:33:44 <jonasschnelli> morcos: fec5c0ea05ec22e12313ce3ec575786f5c52039f -> Merge pull request #6112 -> Thu May 7 18:06:32 2015 +0200
362 2015-06-22 15:33:50 <jonasschnelli> could be totally off-branch
363 2015-06-22 15:34:09 <jonasschnelli> what commit are you looking for?
364 2015-06-22 15:34:56 <morcos> yeah 5159 was merged on may 13th.  the old fee estimates are basically useless.
365 2015-06-22 15:34:58 <jtimon> cfields do you have a commit where you separate the "statefull" part of chainparams into different files?
366 2015-06-22 15:35:22 <sipa> jtimon: what is stateful about chainparams?
367 2015-06-22 15:35:51 <jtimon> the globals hidden behind Params() and BaseParams()
368 2015-06-22 15:36:12 <morcos> i have several idea on improving the fee estimates though, which i think are now a potentially much higher priority
369 2015-06-22 15:36:26 <jonasschnelli> morcos: +1
370 2015-06-22 15:37:56 <jtimon> morcos I'm working on moving more code to policy/fee, ideally minRelayTxFee will only be there as an attribute
371 2015-06-22 15:38:49 <morcos> jtimon: great.  i'm happy to help reviewing when i get back to working.. i've hardly been in front of a computer the last couple of weeks.
372 2015-06-22 15:39:21 <jtimon> morcos great, review is always very welcomed!
373 2015-06-22 15:40:06 <sipa> jtimon: why should those go into different files?
374 2015-06-22 15:40:35 <jtimon> morcos my plan is to completely decouple txmempool from policy/fees and I think that won't be very difficult
375 2015-06-22 15:41:19 <jtimon> sipa my idea was moving most globals (currently in main) to globals/server
376 2015-06-22 15:41:49 <sipa> jtimon: wait, what does that have to do with chainparams?
377 2015-06-22 15:41:52 <morcos> jtimon: i wonder if its worth concentrating on other reorgs while there is so much interest in rewriting the way the mempool works
378 2015-06-22 15:42:05 <jonasschnelli> block at hight 362051 (18mins old) only contains one transaction?!
379 2015-06-22 15:42:53 <chmod755> yep...
380 2015-06-22 15:43:24 <jtimon> cfields was planning on creating chainparamsbase_state and chainparams_state so they could be globals/chainparamsbase and globals/chainparams and I could use globals/policy as an intermediary place before turning them into attributes of CStandardPolicy
381 2015-06-22 15:43:59 <jtimon> morcos it will be far easier to rewrite the mempool if there's nothing policy-related in it
382 2015-06-22 15:44:00 <morcos> the mempool and fees/policy are going to need to be tied together in some way.  the mempool kind of has to be aware of two policies, the one you want to keep and the one you're estimating all miners together approximate (for fee estimation), and then you have to decide which of those policies you should use for booting things from the mempool if it grows to big..
383 2015-06-22 15:45:03 <morcos> or whose idea was it just to exponentially increase the min fee as the mempool size grows...  i kind of liked that idea too, seems so simple
384 2015-06-22 15:46:21 <jtimon> morcos my plan was to call the estimator method's before or after the mempool ones, alternatively the mempool class could use mempoolbase and the estimator, leaving mempoolbase decoupled from policy
385 2015-06-22 15:47:42 <jtimon> the very first step to remove minRelayTxFee as a global is certainly moving IsDust out of primitives/transaction
386 2015-06-22 15:48:01 <sipa> yes, IsDust has no place in primitives
387 2015-06-22 15:48:51 <morcos> well either way i have no objection... and seems like those first steps make sense..   but i just think the whole interaction between fee estimation / block creation / mempool could change drastically.
388 2015-06-22 15:49:20 <morcos> but who knows when that could happen
389 2015-06-22 15:53:18 <jtimon> sipa I'll reopen #5114 as dependent on #6068 which I'm changing anywway to fix #5180 (hopefully this will be the last time I do changes  in #6068)
390 2015-06-22 15:56:15 <jtimon> let me finish the code, in the meantime "reviewing" #6051 is also helpful for policy-code encapsulation longer term and you could set me free from one of my rebase mouse-wheels
391 2015-06-22 16:00:54 <petertodd> morcos: that was my idea, and it seemed so simple until I remembered that minRelayTxFee is a global :)
392 2015-06-22 16:03:06 <jtimon> petertodd review of policy encapsulation is very welcomed if you're worried about minRelayTxFee being a global
393 2015-06-22 16:04:11 <jtimon> seems unrelated, but hopefully it will get more clear when I reopen #5114 today
394 2015-06-22 16:05:17 <morcos> petertodd: if you'd had that idea a couple weeks earlier i think with conservative parameters we should have just added it for 0.11.   What makes it so hard that its global, or it just feels icky?
395 2015-06-22 16:05:50 <jtimon> also seemingly unrelated #6163 reduces the couplding with globals
396 2015-06-22 16:06:34 <petertodd> morcos: if I'm correct, it'd be totally ok with the global, it's just you have to change every use of it to some kind of GetMinRelayFee() function with a lock at least
397 2015-06-22 16:06:44 <petertodd> morcos: not a huge deal, but annoying
398 2015-06-22 16:08:20 <morcos> oh yes i see...   well hopefully one of us will remember to put it in for 0.12 if we don't get a more comprehensive mempool janitor in place, which seems a bit ambitious for 0.12
399 2015-06-22 16:10:49 <cfields> jtimon: yes, I'm still planning on that. I'm just doing it one chunk at a time. #6242 is the current one, i need to get that one rebased and fixed up, then I'll move on to the next one. Once no other dependencies remain, I'll move the stateful stuff out
400 2015-06-22 16:11:13 <jtimon> petertodd a deprecated-from-birth GetMinRelayFee() is also part of my plans
401 2015-06-22 16:12:43 <petertodd> jtimon: great!
402 2015-06-22 16:13:15 <petertodd> jtimon: other than that annoyance, I'm pretty sure this exponential mempool thing is very easy to implement
403 2015-06-22 16:14:46 <jtimon> cfields that's the open one, once you showed me a commit separating the chainparams globals into different files, don't you still have that in a longer branch or something
404 2015-06-22 16:14:52 <morcos> how would you see it interacting with non-upgraded clients?
405 2015-06-22 16:15:19 <petertodd> morcos: same way they interact with any mempool inconsistency :)
406 2015-06-22 16:15:34 <cfields> jtimon: yea, somewhere
407 2015-06-22 16:15:36 <jtimon> petertodd it's surprising how often the lack of proper policy code encapsulation gets in the way of apparently-simple-to-implement ideas
408 2015-06-22 16:16:42 <morcos> yeah i mean maybe its not worse than mempools blowing up, but if we eventually move to less conservative relay rate increases then you'd want to be sure that at least fee estimation was giving you high enough numbers to get your transactions relayed or something
409 2015-06-22 16:16:51 <petertodd> jtimon: heh
410 2015-06-22 16:17:53 <jtimon> cfields I mean I want to incorporate something like that in #6229 (hopefully getting your attention) and rebasing your commit is the most lazzy way to give you credit but it's fine if you don't remember where it is
411 2015-06-22 16:17:54 <cfields> jtimon: i think this is what you're talking about? https://github.com/theuni/bitcoin/commit/123f3b0dcef29355060290d56138ff99be212007
412 2015-06-22 16:18:35 <cfields> jtimon: well it doesn't make much sense to do until chainparams has dropped all other app dependencies, so I was waiting to do that
413 2015-06-22 16:20:20 <jtimon> cfields yeah exactly that
414 2015-06-22 16:20:38 <cfields> jtimon: and this one before it, then: https://github.com/theuni/bitcoin/commit/8425a5a02e9ec74b5579ce192e6a8f09b892e89f
415 2015-06-22 16:20:38 <jtimon> I mostly want it as motivation for other chainparam changes
416 2015-06-22 16:22:58 <jtimon> cfields CUnitTestParams ? wtf? https://github.com/theuni/bitcoin/commit/8425a5a02e9ec74b5579ce192e6a8f09b892e89f#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R274
417 2015-06-22 16:22:58 <jtimon> I thought CUnitTestParams was finally killed in https://github.com/theuni/bitcoin/pull/27
418 2015-06-22 16:23:11 <cfields> jtimon: yes, that branch is ancient
419 2015-06-22 16:23:30 <cfields> it's from here: https://github.com/theuni/bitcoin/commits/consensus-refactor
420 2015-06-22 16:23:50 <cfields> I've been slowly picking stuff out of it for merge. Looking through, it looks like it's almost in now, in one form or another
421 2015-06-22 16:25:03 <jtimon> cfields do you have any concern with #6235 ?
422 2015-06-22 16:25:27 <jtimon> I mean, is really a throw worse than an assert?
423 2015-06-22 16:26:36 <cfields> jtimon: er yes actually.. that makes chainparams depend on app translation stuff
424 2015-06-22 16:26:38 <jtimon> cfields what do you think about the factories in #6229 and #6068 ?
425 2015-06-22 16:27:18 <jtimon> cfields not if combined with some parts of #6229
426 2015-06-22 16:27:21 <cfields> er, maybe not. I guess those could be moved out to the globals
427 2015-06-22 16:28:10 <jtimon> only the initialization one, the help one is globalless
428 2015-06-22 16:28:24 <cfields> yes, sorry, misread. I thought those were moved into the classes. no problem.
429 2015-06-22 16:28:43 <jtimon> what about the cointainers?
430 2015-06-22 16:30:04 <jtimon> anyway I should finish the policy thing I have open
431 2015-06-22 16:30:06 <cfields> the singletons, you mean?
432 2015-06-22 16:31:11 <cfields> if so, i haven't looked in detail, but that seems like a nice alternative to the current globals
433 2015-06-22 16:31:19 <jtimon> after I force push can you review #6068 as if it was chainparams (meaning all the feedback I get there is reusable for #6229 and viceversa)
434 2015-06-22 16:33:06 <jtimon> cfields cool, I'll let you know when  #6068 is ready for review again (although it shouldn't change that much)
435 2015-06-22 16:33:23 <cfields> ok
436 2015-06-22 16:52:26 <wangchun> Block 361570 is 999999 bytes in size.
437 2015-06-22 16:57:56 <C-Otto> cool
438 2015-06-22 16:58:32 <wallet42> wangchun: 1000000 allowed?
439 2015-06-22 16:59:16 <wangchun> wallet42: yes
440 2015-06-22 18:10:39 <aliakbar> hey guys, i'm trying to modify the source code a bit in order to gain some information printed on screen: how can i access a connected peer's active chain's tip after a fork?
441 2015-06-22 18:12:22 <aliakbar> is this possible? setInventoryKnown seems to include all known blocks ever mined.
442 2015-06-22 18:15:06 <sipa> look for something like pindexLastCommon or so
443 2015-06-22 18:15:10 <sipa> in main.cpp
444 2015-06-22 18:15:33 <sipa> that tracks our best block which we know the peer has too
445 2015-06-22 18:15:58 <aliakbar> ok thanks!
446 2015-06-22 18:23:50 <kanzure> hard-fork proposal http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009000.html
447 2015-06-22 18:25:28 <kanzure> doesn't this need to be rebased?
448 2015-06-22 18:25:37 <kanzure> out of xt commits
449 2015-06-22 18:25:49 <kanzure> (i thought the branch was on top of xt stuff?)
450 2015-06-22 19:28:52 <kanzure> testnet large block proposal http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009004.html
451 2015-06-22 19:30:26 <nkuttler> i run a testnet faucet. not big, but i'd be happy to help this effort
452 2015-06-22 20:07:03 <C-Otto> is the new mailing list live? i did not receive a single mail...
453 2015-06-22 20:09:10 <sipa> yes
454 2015-06-22 20:09:39 <C-Otto> ok, thank you. i'll check.
455 2015-06-22 20:11:58 <C-Otto> ah, procmail is ... tricky.
456 2015-06-22 20:19:21 <dhill> procmail should be unused
457 2015-06-22 20:21:56 <C-Otto> dhill: let's not discuss this here
458 2015-06-22 20:22:01 <dhill> :)
459 2015-06-22 20:22:21 <C-Otto> rather: is there a manual how to run a TEST full node? I like peter's thought, and I'd like to pitch in a few GBit/sec and TByte
460 2015-06-22 20:22:24 <dhill> my mainnet mempool is over 10000
461 2015-06-22 20:23:40 <C-Otto> dhill: what's the command to find out?
462 2015-06-22 20:23:55 <C-Otto> getmempoolinfo
463 2015-06-22 20:23:56 <dhill> getmininginfo | grep pool
464 2015-06-22 20:24:06 <C-Otto> you mean size? :)
465 2015-06-22 20:24:12 <dhill> or getrawmempool | wc -l   (-2)
466 2015-06-22 20:24:14 <dhill> number of txs
467 2015-06-22 20:24:38 <C-Otto> I have 10k4 and 10k5 on my nodes
468 2015-06-22 20:25:15 <chmod755> 10,500?
469 2015-06-22 20:25:32 <dhill> yes
470 2015-06-22 20:42:36 <JWU42> Transactions in mempool:11262
471 2015-06-22 20:42:46 <JWU42> silly...
472 2015-06-22 20:52:55 <jonasschnelli> dhill: use getmempoolinfo and avoid loosing cpu ticks with | wc -l :-)
473 2015-06-22 21:49:53 <Happzz> i think these guys have made their point
474 2015-06-22 21:49:57 <Happzz> bitcoin is lagging to hell
475 2015-06-22 21:51:05 <phantomcircuit> Happzz, only very recently versions of bitcoin core wallet support fee estimation
476 2015-06-22 21:51:15 <phantomcircuit> more engineering work is needed in this area
477 2015-06-22 21:52:22 <Happzz> im not sure what you're saying, but im sure as hell bitcoin is lagging because of some fucktards.
478 2015-06-22 21:52:41 <Happzz> although im not so sure they're fucktards. they're more than likely doing us all a huge favor.
479 2015-06-22 21:53:07 <Happzz> im just hoping that whoever has the knowledge how to handle this will pick this glove up
480 2015-06-22 21:53:13 <gmaxwell> Happzz: dunno what you're talking about, but there is basically no backlog of txn that aren't involved in their flooding right now.
481 2015-06-22 21:53:58 <jgarzik> {
482 2015-06-22 21:53:58 <jgarzik> }
483 2015-06-22 21:53:58 <jgarzik> "bytes": 13471220
484 2015-06-22 21:53:58 <jgarzik> jgarzik@ubuntu:~$ ~/repo/bitcoin/src/bitcoin-cli getmempoolinfo
485 2015-06-22 21:53:58 <jgarzik> "size": 6298,
486 2015-06-22 21:54:04 <jgarzik> not much at all, here
487 2015-06-22 21:54:30 <Happzz> two of my own transactions, which are obviously not involved, are still unconfirmed for 6+ hours
488 2015-06-22 21:54:46 <sdaftuar> fees to get confirmed quickly are still pretty small -- eg take a look here at the latest fee estimates: http://core2.bitcoincore.org/smartfee/
489 2015-06-22 21:54:50 <Happzz> 259 bytes, 0.00001 BTC fee
490 2015-06-22 21:55:52 <gmaxwell> e.g. on eligius which is filtering out that parties transaction the blocktemplate size is currently 132KB.
491 2015-06-22 21:57:06 <jgarzik> /Bither1.2.1/ is a new one
492 2015-06-22 21:57:53 <DiabloD3> gmaxwell: so
493 2015-06-22 21:58:01 <DiabloD3> you know how I updated a years worth of shit?
494 2015-06-22 21:58:01 <jgarzik> and an ancient, stuck one:
495 2015-06-22 21:58:06 <DiabloD3> that went a LOT faster than bitcoin used to go
496 2015-06-22 21:58:07 <jgarzik> /bitcoinseeder:0.01/: version 60000, blocks=230000, us=167.88.46.204:8333, peer=12303, peeraddr=176.9.45.239:45467
497 2015-06-22 21:58:34 <jgarzik> DiabloD3, sure, http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
498 2015-06-22 21:58:46 <CodeShark> how do you change the settings on the new bitcoin-dev mailing list? https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev only provides an interface to either create a new account or do an admin login
499 2015-06-22 21:59:03 <DiabloD3> jgarzik: well bitcoin used to be fast until all the betting sites appeared
500 2015-06-22 21:59:13 <DiabloD3> jgarzik: did they all die off or something?
501 2015-06-22 21:59:23 <jgarzik> most died off
502 2015-06-22 22:00:05 <wizkid057> still a few that refuse to die :(
503 2015-06-22 22:00:37 <DiabloD3> used to take a day to do a month
504 2015-06-22 22:01:05 <DiabloD3> now it took a day for a year
505 2015-06-22 22:01:10 <DiabloD3> not even a day
506 2015-06-22 22:02:06 <wizkid057> DiabloD3: I sync'd a 0.10 node on a low-end dual core machine with a crappy HDD... started it last night at ~4AM... 6PM now and it's only about 60 days behind realtime.  all from p2p
507 2015-06-22 22:02:38 <wizkid057> pretty impressive leap from a couple of years ago
508 2015-06-22 22:04:38 <gmaxwell> And I'm cringing thinking egads thats slow.
509 2015-06-22 22:04:54 <DiabloD3> yeah
510 2015-06-22 22:04:58 <DiabloD3> thats a lot faster than it used to be
511 2015-06-22 22:05:07 <DiabloD3> did headers first get merged in?
512 2015-06-22 22:05:33 <wizkid057> gmaxwell: this is some 2GHz AMD dual core machine with a ~5k RPM 2.5" HDD lol
513 2015-06-22 22:06:24 <wizkid057> DiabloD3: yeah, looks that way
514 2015-06-22 22:06:58 <DiabloD3> I don't think disk IO is a big factor with me
515 2015-06-22 22:07:02 <DiabloD3> at least I hope its not
516 2015-06-22 22:07:24 <DiabloD3> used to be 2x2TB running zfs, now 2x2TB + 2x m550 128gb with zfs l2arc+zil
517 2015-06-22 22:07:33 <DiabloD3> it shouldn't be making that big of a difference
518 2015-06-22 22:07:35 <wizkid057> this machine is mostly CPU bound... few %wait
519 2015-06-22 22:07:47 <DiabloD3> yeah, I didn't even really increase the cpu
520 2015-06-22 22:08:15 <DiabloD3> went from core 2 duo e8500 on my workstation, upgraded that workstation massively, but now the miniserver bitcoin is running on is a dual core i3
521 2015-06-22 22:08:28 <DiabloD3> I'd be surprised if its getting over 50% more cpu time
522 2015-06-22 22:09:03 <DiabloD3> memory bandwidth didnt usefully increase, went from ddr2-1066 to ddr3-1600 (ergo, memory latency theoretically went up, but bandwidth increased 50%)
523 2015-06-22 22:09:17 <wizkid057> for comparison, I processed the entire chain from block*.dat files on a 12 core machine with RAID10 SSDs in ~90 minutes
524 2015-06-22 22:09:25 <wizkid057> with 0.10
525 2015-06-22 22:09:47 <DiabloD3> heh, I didn't know it had a thing for parallel checking now
526 2015-06-22 22:10:15 <wizkid057> core devs have been on top of things :)
527 2015-06-22 22:10:17 <wizkid057> kudos
528 2015-06-22 22:10:28 <CodeShark> sipa has been on top of it ;)
529 2015-06-22 22:10:56 <CodeShark> it was something being worked on for a long time, actually
530 2015-06-22 22:11:04 <DiabloD3> sipa needs to add
531 2015-06-22 22:11:07 <DiabloD3> and
532 2015-06-22 22:11:07 <DiabloD3> parallel block download
533 2015-06-22 22:11:12 <DiabloD3> upload limiting
534 2015-06-22 22:11:15 <wizkid057> DiabloD3: parallel download is done
535 2015-06-22 22:11:19 <wizkid057> and working
536 2015-06-22 22:11:23 <DiabloD3> oh, is it in stable yet?
537 2015-06-22 22:11:30 <wizkid057> pretty sure
538 2015-06-22 22:11:54 <DiabloD3> maybe thats what did it for me
539 2015-06-22 22:12:05 <DiabloD3> I have faster internet now, but only 6mbps -> 15
540 2015-06-22 22:12:07 <wizkid057> next we need GPU accelerated signature checking :P
541 2015-06-22 22:12:10 <DiabloD3> but it used to not even bother maxing that out
542 2015-06-22 22:12:17 <DiabloD3> wizkid057: thats trivial to add
543 2015-06-22 22:12:22 <phantomcircuit> DiabloD3, at current sizes bitcoin is definitely cpu limited
544 2015-06-22 22:12:35 <phantomcircuit> DiabloD3, unfortunately it's not
545 2015-06-22 22:12:42 <DiabloD3> I mean, the code already exists
546 2015-06-22 22:12:44 <DiabloD3> I wrote it
547 2015-06-22 22:12:45 <DiabloD3> just use it
548 2015-06-22 22:12:46 <phantomcircuit> DiabloD3, you'd need to run the entire script though the gpu
549 2015-06-22 22:12:50 <phantomcircuit> not just the signatures
550 2015-06-22 22:12:53 <DiabloD3> oh
551 2015-06-22 22:13:02 <DiabloD3> well whatever
552 2015-06-22 22:13:06 <DiabloD3> cpus are now getting so fast
553 2015-06-22 22:13:08 <DiabloD3> that its not an issue
554 2015-06-22 22:13:16 <wizkid057> well, GPU accelerated block verification then hehe
555 2015-06-22 22:13:25 <phantomcircuit> you're not going to rewrite the script engine in opencl and expect to maintain consensus compatability :P
556 2015-06-22 22:13:44 <DiabloD3> phantomcircuit: yeah because who the fuck wants to write opencl, ugh
557 2015-06-22 22:13:51 <DiabloD3> I mean, it almost looks like C!
558 2015-06-22 22:13:52 <hearn> phantomcircuit: why?
559 2015-06-22 22:13:53 <DiabloD3> we cant have that!
560 2015-06-22 22:14:03 <DiabloD3> hearn: multiple versions of code that have to remain the same
561 2015-06-22 22:14:11 <DiabloD3> although if you just write code that outputs code, you're fine
562 2015-06-22 22:14:11 <phantomcircuit> hearn, why?
563 2015-06-22 22:14:13 <hearn> no, i mean, why do you have to run scripts on the cpu
564 2015-06-22 22:14:13 <phantomcircuit> are you serious
565 2015-06-22 22:14:15 <hearn> gpu
566 2015-06-22 22:14:23 <phantomcircuit> hearn, because OP_CHECKSIG NOT
567 2015-06-22 22:14:25 <DiabloD3> you cant run the scripts on the gpu anyhow
568 2015-06-22 22:14:36 <DiabloD3> gpus arent meant to run code like that
569 2015-06-22 22:14:43 <DiabloD3> if its branchy, loopy, or jumpy, it isnt gpuy.
570 2015-06-22 22:14:52 <CodeShark> you can still check signatures on GPU and then evaluate scripts using the signature validation results
571 2015-06-22 22:14:55 <hearn> phantomcircuit: so? you speculate
572 2015-06-22 22:14:58 <DiabloD3> now, a phi otoh
573 2015-06-22 22:15:11 <phantomcircuit> unless you want to write a script tracer than can indicate whether the result of the OP_CHECKSIG needs to be true or false for the script to succeed
574 2015-06-22 22:15:24 <hearn> most scripts are of a standard form anyway
575 2015-06-22 22:15:36 <hearn> you'd certainly get a big speedup with the chain as it is today
576 2015-06-22 22:17:59 <CodeShark> we're going to hit a barrier with this approach sooner or later anyhow
577 2015-06-22 22:18:20 <CodeShark> even with the best tech it's still going to take way too long to do an initial sync
578 2015-06-22 22:18:22 <phantomcircuit> hearn, there is also some serious memory issues there
579 2015-06-22 22:18:58 <hearn> CodeShark: signatures are only checked after the last checkpoint, right
580 2015-06-22 22:19:00 <phantomcircuit> hearn, i would actually be kind of surprised if that was significantly faster overall than cpu validation with libsecp256k1
581 2015-06-22 22:19:07 <hearn> you may well be right
582 2015-06-22 22:19:19 <phantomcircuit> that's not a security measure
583 2015-06-22 22:19:24 <hearn> i do not know whether gpu acceleration would help improve things. just pointing out that script execution and sig checking can be separated
584 2015-06-22 22:21:16 <theorbtwo> Part of the question is which is getting bigger faster -- the number of signatures we have to check, or the speed at which we can check them?
585 2015-06-22 22:21:50 <theorbtwo> I suspect that offloading op_checksig's hard bits, but keeping general script execution in the CPU, is probably the better part of valour.
586 2015-06-22 22:23:29 <theorbtwo> If there are only a small number of scripts that account for almost all transactions, then it may be useful to check for one of those scripts and forward to a purpose-written function ... but profile first.
587 2015-06-22 22:24:53 <CodeShark> problem with that is it makes it too easy to DoS
588 2015-06-22 22:26:11 <CodeShark> it's dangerous to make assumptions like "most scripts are in a specific format"
589 2015-06-22 22:27:44 <hearn> i thought we were talking about initial sync speed
590 2015-06-22 22:28:37 <CodeShark> yes, true - but then we'd have to be adaptive if the transaction distribution changes
591 2015-06-22 22:29:21 <CodeShark> but yes, correct - if you're talking about validating the history up until now, it's a fairly safe assumption that most transactions are in specific formats...assuming the volume is not growing exponentially
592 2015-06-22 22:29:26 <phantomcircuit> hearn, i dont believe you can write a general op_checksig offloading system
593 2015-06-22 22:29:47 <phantomcircuit> hearn, maybe you can build something that is efficient with the current standard transaction
594 2015-06-22 22:30:06 <phantomcircuit> but probably not by anywhere near as much as i suspect people would expect
595 2015-06-22 22:30:38 <CodeShark> I'm not sure it's worth the effort to optimize for a few transaction types - especially given that we're about to see an explosion of a bunch more script types
596 2015-06-22 22:31:42 <CodeShark> and if we ever do want to go mainstream, we will have exponential growth in volume (at least until it saturates)
597 2015-06-22 22:33:11 <CodeShark> validating the history from 2009 until 2015 will probably be faster than validating the history from 2015 to 2017 :)
598 2015-06-22 22:33:25 <CodeShark> by at least an order of magnitude if not several
599 2015-06-22 22:55:00 <CodeShark> I think it's pretty safe to say we've basically hit a scalability wall with validation
600 2015-06-22 23:18:29 <leakypat> Goddamn spammers
601 2015-06-22 23:19:40 <leakypat> Filling my expensive disk space up with twice the usual spam
602 2015-06-22 23:20:01 <phantomcircuit> CodeShark, there is some amount of head room available by adding a new validation state
603 2015-06-22 23:20:18 <phantomcircuit> currently there is a brief period between blocks in which the cpu isn't 100% utilized
604 2015-06-22 23:20:35 <phantomcircuit> it's maybe an additional 10-25% on very powerful computers
605 2015-06-22 23:20:55 <Luke-Jr> leakypat: thanks, that sarcasm made me realise why I keep dropping off IRC today.
606 2015-06-22 23:22:06 <moa> leakypat: bitcoin is a system where you knowingly devote disk space and bandwidth to processing very expensively hashed garbage
607 2015-06-22 23:22:14 <CodeShark> phantomcircuit: we're still never going to achieve exponential (or probably even quadratic) improvements over where we are now...so we're still hitting a wall
608 2015-06-22 23:23:22 <CodeShark> not to say we shouldn't try to squeeze an extra 10-25% if we can
609 2015-06-22 23:23:56 <CodeShark> but this is by far the biggest bottleneck to scaling the network out
610 2015-06-22 23:24:14 <CodeShark> I wish 5% of the effort placed on the larger block thing were put into scalability ;P
611 2015-06-22 23:25:19 <Emcy> surely bandwidth is the biggest
612 2015-06-22 23:25:47 <Emcy> its the only involved technology that has incentives to reduce over time, relatively
613 2015-06-22 23:25:52 <CodeShark> validation is biggest - bandwidth could be significantly optimized with algorithmic improvements
614 2015-06-22 23:26:26 <theorbtwo> The real question, IMHO, is if the blockchain is growing faster then the speed of verification (including moore's law related gains).  That's the breakeven point -- if verification grows faster, then initial run will get faster, if chain grows faster, then initial run will get slower, and eventually we won't even be able to keep up with ongoing transactions and the whole thing falls over.
615 2015-06-22 23:26:39 <moa> CodeShark: 'scaling' is an ill-defined term, are you referring to users, transactions, nodes or something else?
616 2015-06-22 23:26:53 <CodeShark> anyone who's been synching bitcoin nodes for a few years now knows the answer to that, theorbtwo  :p
617 2015-06-22 23:27:25 <Emcy> well we know intel is holding back really hard dont we
618 2015-06-22 23:27:35 <CodeShark> headers first sync was the last significant algorithmic boost...but there aren't too many more algorithmic improvements that don't require protocol changes
619 2015-06-22 23:27:38 <Emcy> cos AMD goofed this generation of cpus
620 2015-06-22 23:28:23 <CodeShark> moa: I'm referring to being able to have a period of exponential growth in usage without bogging down the current infrastructure
621 2015-06-22 23:28:44 <moa> so scaling 'usage'
622 2015-06-22 23:28:45 <Luke-Jr> CodeShark: you forget libsecp256k1
623 2015-06-22 23:29:01 <CodeShark> oh, right, Luke-Jr - that was also a useful thing
624 2015-06-22 23:29:09 <Luke-Jr> will be* ;)
625 2015-06-22 23:29:17 <theorbtwo> CodeShark: That's what I think too, which means that we need to fix it, even if it's going to take protocol changes.
626 2015-06-22 23:33:26 <CodeShark> Luke-Jr: libsecp256k1 is definitely worthwhile...but at best it represents a constant scaling factor
627 2015-06-22 23:34:29 <CodeShark> we need O(log n) validation :)
628 2015-06-22 23:35:23 <CodeShark> it's the only way we'll reasonably ever get hundreds of millions or billions of users
629 2015-06-22 23:41:22 <nwilcox> If it's purely new full node startup at issue, perhaps a reasonable tradeoff is to only verify headers, assuming miners wouldn't put work behind "invalid" transactions.
630 2015-06-22 23:41:46 <nwilcox> -or to do that, and then randomly select a subset of transactions to validate.
631 2015-06-22 23:42:01 <CodeShark> headers-only to checkpoint, then full + txout commitment would help some - but it's still not a 100% satisfactory solution, IMO
632 2015-06-22 23:42:15 <gmaxwell> nwilcox: you cannot currently, efficiently, randomly validate transactions in the protocol design of bitcoin.
633 2015-06-22 23:42:28 <nwilcox> gmaxwell: I realize that.
634 2015-06-22 23:42:53 <nwilcox> And I suppose selecting a random transaction, then validating backwards along txins will quickly touch many many transactions, eh?
635 2015-06-22 23:43:09 <gmaxwell> (and not checking at all and trusting miners is equivilent to SPV, which you certantly can do)
636 2015-06-22 23:43:56 <gmaxwell> nwilcox: you cannot validate backwards efficiently in the currently system (not sure if you were aware of that).  Yes the transaction graph grows very rapidly.
637 2015-06-22 23:44:25 <gmaxwell> This speculative stuff doesn't really belong in this channel, please take it to -wizards or something. I'm losing the ability to follow the discussion here completely.
638 2015-06-22 23:44:47 <CodeShark> this isn't speculative - this is math :p
639 2015-06-22 23:45:17 <nwilcox> I apologize for being off topic.
640 2015-06-22 23:45:25 <CodeShark> but fine, let's take it to wizards