--- Day changed Mon Dec 28 2015
00:10 -!- Amnez777 [~Amnez777@37.157.216.149] has quit [Ping timeout: 260 seconds]
00:44 -!- Amnez777 [~Amnez777@37.157.216.149] has joined #bitcoin-core-dev
00:46 -!- Amnez777 [~Amnez777@37.157.216.149] has quit [Changing host]
00:46 -!- Amnez777 [~Amnez777@unaffiliated/amnez777] has joined #bitcoin-core-dev
00:58 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has joined #bitcoin-core-dev
01:29 -!- Tera2342 [~Tera2342@223.207.233.83] has joined #bitcoin-core-dev
01:30 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
01:31 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ixhmdkwzlfrtqnnt] has joined #bitcoin-core-dev
01:34 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:55 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
02:21 -!- raedah [~raedah@172.56.38.34] has quit [Quit: Leaving]
02:38 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving]
02:39 -!- wangchun [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
02:40 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 276 seconds]
02:49 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
02:50 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
02:51 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
03:00 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 245 seconds]
03:19 -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has joined #bitcoin-core-dev
03:30 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
03:34 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
04:13 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
04:38 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds]
04:39 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
05:20 < Luke-Jr> anyone happen to remember what the whitelist-peer hack is needed to get RPC tests to pass on 0.10/0.11? :/
05:42 -!- p15 [~p15@24.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 256 seconds]
06:16 -!- Tera2342 [~Tera2342@223.207.233.83] has quit [Ping timeout: 260 seconds]
06:17 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has joined #bitcoin-core-dev
06:17 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-mjijublbtrqkmzzq] has quit [Ping timeout: 264 seconds]
06:19 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-dmsceratfewfnizl] has joined #bitcoin-core-dev
06:46 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
06:54 -!- civos [~civ0s@50.248.81.65] has quit [Quit: Leaving]
07:14 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-dmsceratfewfnizl] has quit [Ping timeout: 256 seconds]
07:16 -!- cryptopeddler [NSA@gateway/vpn/mullvad/x-uvggemzhwrbqsxlz] has joined #bitcoin-core-dev
08:09 -!- tripleslash_t [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
08:11 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds]
08:23 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:24 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 245 seconds]
08:35 -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-core-dev
08:44 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Remote host closed the connection]
08:56 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
08:56 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
09:17 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
09:22 -!- MarcoFalke [05c7b6cb@gateway/web/cgi-irc/kiwiirc.com/ip.5.199.182.203] has left #bitcoin-core-dev []
09:47 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
09:49 -!- jayd3e [~jayd3e@207-181-211-167.c3-0.hnc-ubr1.chi-hnc.il.cable.rcn.com] has joined #bitcoin-core-dev
10:02 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: Konversation terminated!]
10:03 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
10:44 -!- jcorgan is now known as jcorgan|away
10:49 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
10:59 < jayd3e> I'm receiving this error "scheduler.h:14:35: fatal error: boost/chrono/chrono.hpp: No such file or directory", even though I have installed libboost-dev-all
11:00 < jayd3e> followed the directions for 12.04 exactly
11:00 < phantomcircuit> jayd3e, iirc chrono is missing in older versions of ubuntu
11:01 < jayd3e> so use 14.04?
11:02 < jayd3e> phantomcircuit: 
11:02 < phantomcircuit> jayd3e, sorry i dont know which ubuntu versions will work
11:02 < phantomcircuit> i dont think 12.04 will though
11:02 < jayd3e> kk
11:34 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 250 seconds]
11:42 -!- gijensen [~gijensen@gijensen.xyz] has quit [Ping timeout: 246 seconds]
11:47 -!- raedah [~raedah@172.56.38.34] has joined #bitcoin-core-dev
11:49 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev
11:50 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
12:07 -!- jcorgan|away is now known as jcorgan
12:20 -!- c-cex-finch [uid120855@gateway/web/irccloud.com/x-lhcjulyppgiogdzz] has joined #bitcoin-core-dev
12:59 -!- neilf [~neilf@40.121.88.219] has joined #bitcoin-core-dev
13:01 -!- zookolaptop [~user@68.233.157.2] has quit [Ping timeout: 245 seconds]
13:37 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
13:37 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
13:38 -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-core-dev
13:52 -!- Guest1038 [~socrates1@li175-104.members.linode.com] has quit [Changing host]
13:52 -!- Guest1038 [~socrates1@unaffiliated/socrates1024] has joined #bitcoin-core-dev
13:52 -!- Guest1038 is now known as amiller
13:59 -!- raedah [~raedah@172.56.38.34] has quit [Ping timeout: 250 seconds]
13:59 < morcos> CodeShark: sorry, dirty way of getting your attention
14:00 < CodeShark> No worries :)
14:00 < morcos> Are we still trying to get this rolled out as the next soft fork
14:00 < morcos> if so we should be concentrating core development effort on all of these things so we can show progress.  versionbits, BIP68/CSV, segwit
14:01 < morcos> but there doesn't seem to have been any movement on the versionbits PR for quite some time
14:01 < btcdrak> who is doing the final implementation now, CodeShark or rusty?
14:01 < morcos> oh
14:01 < morcos> see i didn't know about that
14:01 < CodeShark> I think the segwit testnet has taken priority right now
14:01 < morcos> is there a different implementation?
14:01 < morcos> is that something that is being worked on?
14:02 < morcos> i asked sipa about that earlier and he didn't reply
14:02 < morcos> where is that happening?
14:02 < btcdrak> morcos: even if versionbits was not ready we can still deploy using ISM though...
14:02 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
14:03 < petertodd> morcos: and there's still my pseudo-versionbits proposal that we can use too
14:03 < morcos> sure i agree we don't have to have versionbits before segwit
14:03 < morcos> i just thought that was what wumpus laid out in his plan
14:04 < petertodd> also, for the record, I would NACK segwit myself without a validationless mining fix
14:04 -!- zookolaptop [~user@68.233.157.2] has quit [Ping timeout: 246 seconds]
14:05 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
14:05 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
14:05 < CodeShark> wanna help implement that, petertodd?
14:06 < petertodd> CodeShark: yes, but note that I have no funding right now for core dev work, so I can't promise anything
14:07 < petertodd> CodeShark: that said, I'm fairly certainly I'll be able to get some soon
14:07 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
14:07 < CodeShark> the short-term objective is to deploy a functional testnet without all the intended features and to set up a framework for adding more features
14:08 < petertodd> CodeShark: makes sense to me
14:09 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
14:09 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
14:10 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 255 seconds]
14:11 < CodeShark> deployment to mainnet is still at least another couple months away, I'd say...once we near that we can figure out which activation mechanism we'll use
14:11 < CodeShark> So versionbits is now on the backburner
14:12 -!- raedah [~raedah@172.56.38.34] has joined #bitcoin-core-dev
14:13 -!- brg444 [18257df2@gateway/web/freenode/ip.24.37.125.242] has quit [Quit: Page closed]
14:14 < CodeShark> If you have some extra time and want to dig in, petertodd, I'd love to hear your suggestions
14:15 < petertodd> CodeShark: well, I'll see that I can do
14:16 -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-core-dev
14:18 < morcos>  /window 24
14:18 < morcos> oops
14:20 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 272 seconds]
14:27 < sipa> petertodd: your suggestion is easy to implement for consensus rules; i just worry about the logic needed to get mining software to support it
14:27 < sipa> anything that changes the coinbase outputs needs extra logic
14:28 < btcdrak> CodeShark: what about rusty, he has code done also.
14:28 < btcdrak> oh wait, wrong conversion :)
14:28 -!- Tera2342 [~Tera2342@223.207.233.83] has joined #bitcoin-core-dev
14:30 < petertodd> sipa: I'm not suggesting changing the coinbase outputs, just committing to something calculated form them
14:31 < petertodd> sipa: equaly, the idea probably would work even without the coinbase output commitment
14:31 < petertodd> sipa: important thing is that miners never soft-fork in a commitment to the prior-block possession proof in the prior block
14:32 < sipa> petertodd: you're suggesting making block X commit to for example H(full block X-1 incl witness, X's coinbase outouts) ?
14:33 < sipa> s/,/||/
14:33 < sipa> right?
14:36 < petertodd> sipa: yes
14:36 < sipa> which means that any software which computes the coinbase outouts will need updated code to compute the commitment
14:37 < petertodd> sipa: right, that's fair
14:37 < sipa> which for example makes the 21 computer incompatible with it
14:37 < petertodd> sipa: so maybe make it commit to H(full block X-1 + nonce) 
14:37 < sipa> ah!
14:37 < sipa> what is nonce?
14:37 < petertodd> sipa: then soft-forking in a later committment to the coinbase outputs is possible, as is anything else
14:38 < petertodd> sipa: it's probably ok if the nonce can be picked arbitrarily - so long as miners don't actually soft-fork in a commitment to that commitment in the previous block, we're ok
14:38 < petertodd> sipa: and in fact, if it's the *full* block that's impossible :)
14:39 < sipa> i'm very interested in including solutions for this, but i think it will need input from people with more experience with mining software/hardware
14:39 < petertodd> sipa: agreed
14:39 -!- Tera2342 [~Tera2342@223.207.233.83] has quit [Ping timeout: 260 seconds]
14:40 < petertodd> sipa: part of why I want to do this now, is because I think if we *don't* fix this, we will have significant pushback on fixing it later
14:40 < sipa> petertodd: also, i think you want the full block data at the end of the hash, so you can't compute a midstate for it
14:40 < petertodd> sipa: IE, we probably will have to allow a validationless mining alternative where you leave off the commitment, in exchange for an empty block
14:41 < petertodd> sipa: well, if the nonce is picked arbitrarily, that's technically not an issue, but yeah, best to do H(nonce + <data>)
14:44 < sipa> petertodd: i mean, you probably want to prevent a setup where someone can send a midstate of the full prevblock
14:45 < sipa> petertodd: i think there may be significant pushback against this already; any device that decides the coinbase but leaves tx selection up to something else will now need to be burdened with full blocks, where it only needed very low bandwidth beforehand
14:47 < petertodd> sipa: well, the fact that you can do that is probably a flaw in the bitcoin protocol
14:47 < morcos> sipa: "pushback against this" you mean segwit itself?
14:47 < petertodd> sipa: I'm just trying to at least get us back to thecurrent situation, where if you do validationless mining you're trusting others
14:48 < petertodd> sipa: IE, don't make the situation worse
14:48 < btcdrak> morcos: against validationless mining fix
14:48 < morcos> but the issue with the coinbase needing more data exists with just segwit
14:49 < petertodd> morcos: not quite - with just segwit the rest of the coinbase outputs can be picked freely
14:50 < sipa> morcos: segwit makes the coinbase input depend on tx selection
14:50 < morcos> petertodd: so what was the reasoning of having it commit to block X's coinbase outputs
14:50 < sipa> morcos: the fact that segwit allows easy mining without validating signatures
14:51 < petertodd> morcos: so, the reasoning of committing to H(nonce + prev-block-data) is to force you to have that data to be able to mine; making it H(coinbase-outputs + prev-block-data) would additionally constrain that calculation to be miner-specific
14:51 < morcos> yes i understand why to commit to previous blocks witness, but the point of it being your coinbase in there is just to prove that the computation had to be done individually for each miner
14:52 < morcos> right, ok
14:52 < petertodd> morcos: like I saidabove, it's probably sufficient to just make it H(nonce+prevblockdata), and if coinbase is worth committing too we can do that later with a H(H(nonce+coinbase)+prevblockdata) softfork
14:53 < morcos> so personally i'm not convinced of why this is so critically important, i think if you don't have enough full nodes validating everything to keep the network honest then we've failed anyway.
14:54 < morcos> the only thing from your email that i found particularly compelling though was maybe there is some gaming behind witholding your witness data
14:54 -!- c-cex-finch [uid120855@gateway/web/irccloud.com/x-lhcjulyppgiogdzz] has quit [Quit: Connection closed for inactivity]
14:54 < petertodd> morcos: sure, but this makes it much easier for miners to skip validating - in practice that'll be a major engineering risk at the very least
14:54 < petertodd> morcos: minres don't like to do anything they don't have too- the existing validationless mining code they run is scary enough
14:54 < morcos> so anyway, to sipas point about pushback..  there would no additional pushback to the H(nonce + prevblockdata) approach then
14:55 < petertodd> morcos: I don't think there would be, same kind of data needed to calculate segwit
14:55 < petertodd> (calcualte it honestly anyway)
14:56 < sipa> petertodd: not true
14:56 < morcos> ok, that was my original confusion
14:56 < petertodd> sipa: why not?
14:56 < sipa> petertodd: with segwit, the code doing the tx selection needs to be able to make coinbase commitments
14:57 < sipa> petertodd: with your proposal (the eventual one), the code doing coinbase output selection needs to be able to make coinbase commitments
14:57 < sipa> this is already not the same hardware in some cases now
14:57 < petertodd> sipa: sure, but I mean the arbitrary nonce version - committing to the coinbae output is *think* optional
14:57 < morcos> sipa: yes but we're talking about just the H(nonce + prev) version
14:57 < sipa> who chooses the nonce?
14:58 < petertodd> sipa: minerdoes
14:58 < petertodd> sipa: they'll probably all choose 0x00 :)
14:58 < sipa> you can construct a validationless mining scheme where everyone just agrees on a constant noncr
14:58 < sipa> *nonce
14:58 < morcos> there are other ways you could make it unique'ish to the miner if that was important, that doesn't depend on coinbase outputs anyway
14:58 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
14:58 < petertodd> sipa: no! because you don't know for sure if the nonce the previous miner gave you with their block is actually correct, and they can't commit to it in the block itself
14:59 < sipa> petertodd: so?
14:59 < sipa> they can make a deal that they have to
14:59 < petertodd> sipa: like I say, that gets us back to the status quo, where such arrangements involve trust
15:00 < petertodd> sipa: I'm certainly not claiming this isa perfect solution, but keeping at least the status quo is important
15:00 < sipa> does segwit-without-witness-validation not give you just a weaker version of that?
15:00 < sipa> that also requires trust, but only trust in valid signatures
15:00 < sipa> rather than trust in fully valid block
15:00 < petertodd> sipa: which is bloody dangerous given how many SPV nodes there are
15:01 < petertodd> sipa: note that my *other* proposed solution was that we allow invalid txs to be committed to in blocks, and have miners commit to the subset that were valid n-1 blocks ago, but I figured that was too far out to get any acceptance
15:01 < sipa> my point is: if they're going to bother not doing full validation, why wouldn't they go all the way
15:02 < sipa> nowitvalidation gives you a small constant factor bandwidth improvememt
15:02 < petertodd> sipa: whatdo you mean by "all the way", empty blocks?
15:02 < sipa> Ah.
15:03 < sipa> now i see the distinction: it requires giving up fees
15:03 < petertodd> indeed
15:03 < petertodd> equally, giving an option to leave out the prev-block posession proof,in exchange for an empty block, is a nice way to make gmaxwell's validationless mining flag actually have some consensus enforced teeth
15:04 < morcos> yeah i guess i agree it could be a step backwards that if you withold your witness data without one of these fixes, other miners won't have the fee incentive to ignore you, and will be more likely to build on top
15:05 < petertodd> yup
15:05 < morcos> thats more compelling to me than the miners won't bother with the witness data
15:06 < petertodd> well, I'm sure some won't bother... it's a lot of engineering work to do it right
15:06 < morcos> so couldn't we just do H(cur block wit data + prev block data) or something to make it unique to miner
15:07 < petertodd> morcos: hmm, actually I think that works
15:07 < morcos> if someone doesn't give you the witness data, you aren't free to pick your own txs to include in the block
15:07 < petertodd> morcos: though you'd have to recalculate the commitment every time you change the tx contents of the block, but that's not too expensive - just hashing a few MB of data
15:08 < petertodd> morcos: makes sense
15:08 < morcos> you have to do that anyway for your own witness commitment
15:08 < petertodd> morcos: yup
15:09 -!- tripleslash_a [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
15:09 < sipa> ... of course, a fraud proof for that requires access to the whole block
15:10 < petertodd> sipa: that's kinda the point :)
15:10 < petertodd> sipa: fraud proofs are themselves a dangerous double-edged sword...
15:11 -!- tripleslash_t [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]
15:12 -!- raedah [~raedah@172.56.38.34] has quit [Quit: Leaving]
15:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
15:25 < sipa> petertodd: i'm aware that you feel that way
15:27 < sipa> i'd prefer a mechanism that didn't preclude compact fraud proofs though
15:28 < petertodd> to use the terminology of banking/fintech, fraud proofs lull you into an ecosystem without strong transaction finality: you never know if there's a fraud proof out there that you're being prevented from learning about via a sybil
15:28 < petertodd> sipa: note how, if you make the prev-block-data commitment into a tree, allowing for a compact fraud proof, you'd simultaneously make it easy and compact to prove that it was correct!
15:30 < sipa> petertodd: but what if the alternative to those who would run partial validation node is not more full node, but more centralized api providers?
15:30 < petertodd> sipa: that said, in that type of scheme, it may be sufficient that the sender of that "proof" can lie about a subset of the tree and get away with it
15:31 < petertodd> sipa: the alternative isn't that, it's that we scale up bitcoin differently
15:31 < sipa> petertodd: i think that question may be independent of scale :)
15:31 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-core-dev
15:31 < sipa> but i understand your concern, and i'm certainly not pushing to get the ecosystem into a fraud proof model now
15:31 < petertodd> sipa: a 4MB fraud proof isn't all that bad
15:32 < petertodd> sipa: remember, right now we have ~50GB fraud proofs :)
15:32 < sipa> aware!
15:34 < sipa> petertodd: "lull you into an ecosystem without strong transaction finality"... isn't that already the case for bitcoin? you never know that the block you saw may be reorganized away
15:34 < sipa> the difference is of course that PoW, under certain assumptions about mining strategies and distribution, allows you to compute an upper bound on the chance for that
15:35 < sipa> and that you can observe long term sybils
15:35 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 256 seconds]
15:35 < sipa> but bitcoin doesn't have the strong transaction finality either as such
15:36 < petertodd> sipa: bitcoin has very strongly *defined* transaction finality: at a given # of confirmations from a point after which you're sure is in the longest chain, you know exactly what it'dcost to reorganize
15:36 -!- raedah [~raedah@172.56.38.34] has joined #bitcoin-core-dev
15:36 < sipa> fair enoigh
15:36 < petertodd> sipa: fraud proofs aren't like that at all
15:36 < sipa> nope, for fraud proofs it is just assuming no censorship
15:36 < petertodd> sipa: especially in an envifronment where we're relying heavily on them
15:37 < petertodd> not quite, remember a fraud proof can't be made from data that you don't have access too, so the actual mechanism of a fraud proof will always be challenge->response - it's not fraud proofs that matter, but rather *non-fraud* proofs
15:37 < sipa> ?
15:38 < sipa> well SNARKs that can encompass the entirety of a block validation would of course solve many things :)
15:39 < kanzure> once the SNARK scheme is figured out, you can often figure out a way to do the same thing without SNARKs
15:42 < petertodd> sipa: with SNARKs even treechains is trivial, so... :)
15:43 < petertodd> sipa: consider the case of a prev-block-possession commitment, proved via merkle tree of H(nonce + <part of prev-block>)
15:43 < sipa> well, if computing the proof takes a google-size datacenter to produce within 10 minutes, we get a different type of centralization concern
15:43 < petertodd> sipa: now, if I commit fraud in that tree, meaning one of the leaves isn't valid, I'm obviously not going to give you that leaf - you'd have a handy fraud proof! instead, I'll distribute all but the data required to prove that fraud
15:44 < petertodd> sipa: now, what'll happen is nodes will notice "hey, how do I know leaf #123 is valid?", and they'll ask they're peers to prove it to them - that's a challenge
15:44 < sipa> petertodd: a partial node wouldn't accept a block that lacks revealing all its commitments
15:44 < petertodd> sipa: the peers will response with a *non-fraud/validity proof*, showing that that part of the block is correct
15:45 < kanzure> wasn't there a proposal about making an explicit commitment(?) to the sum of the values of the outputs
15:45 < petertodd> sipa: however, at no point is a fraud proof ever going to be generated
15:45 < petertodd> sipa: right, but in that case, the partial node doesn't even need fraud proofs
15:45 < sipa> how so?
15:46 < petertodd> sipa:you just said thhe partial node is validating everything relevant...
15:46 < sipa> no
15:46 < petertodd> sipa: IOW, you just said 'full node' and made a typo :)
15:46 < sipa> i said it is receiving everything relevant
15:46 < sipa> not validating it
15:46 < petertodd> sipa: right, in which case it's just a dumb transmitter of information - fraud proofs don't come into it
15:47 < petertodd> sipa: again, in what scenario would the fraudster ever reveal the data required to prove fraud? I'd argue never
15:47 < sipa> petertodd: in that scenario, no node will accept its block
15:48 < sipa> because it is failing to reveal commitments
15:48 < petertodd> sipa: ok, but this goes back transitively - a block may be in itself 100% locally valid, but it's invalid because it depends on an invalid block - why would the partial node eversee thatblock?
15:48 < petertodd> but who forces it to revealthe commitments? fraud challenges!
15:48 < sipa> petertodd: a partial node sees everything; it just doesn't verify everything
15:48 < petertodd> sipa: that's a contradiction...
15:48 < petertodd> sipa: what do you think a partial node sees exactly?
15:48 < sipa> petertodd: all blocks and witnesses
15:49 < sipa> (in the current model, more things can be added of course)
15:49 < petertodd> sipa: all blocks from the genesis block?
15:49 < sipa> down to a block it trusts; that may be the genesis block or not
15:49 < sipa> same as a full node now verifies down to genesis, or gets a utxo set copied from a trusted place
15:50 < petertodd> sipa: right, so again, the only time fraud ever comes into it is fraud in a block prior to the one it trusts
15:50 < sipa> that makes no sense
15:50 < petertodd> sipa: and again, under what circumstance would the fraudster ever give that partial node the data necessary to prove fraud?
15:50 < petertodd> sipa: like, come up with a concrete example!
15:50 < sipa> i said no node accepts without seeing the commitment
15:51 < sipa> there is no need to prove fraud
15:51 < sipa> nobody accepts it
15:51 < petertodd> sipa: ok, so... I think we're in violent agreement :) I'm just saying, there's actually no scenario where fraud proofs themselves make sense - what's actually important is fraud challenges, responded to via local validity proofs
15:52 < sipa> i disagree
15:52 < petertodd> ok, so where's the concrete example of a fraud proof?
15:52 < sipa> for example, you could build a node that maintains only a utxo set for txids whose hash starts with a 0
15:52 < petertodd> right
15:53 < sipa> the assumption is that other nodes are either full, or do together validation for all txids whose hash starts with (not 0)
15:53 < petertodd> right
15:53 < sipa> and that you're not censored from them
15:53 < sipa> this partial node would still download full blocks and witnesses
15:53 < petertodd> sure, so when exactly does the fraud proof get generated?
15:54 < sipa> and will not accept a block that hash merkle malleability, pow failure, mismatching txids, mismatching witness hashes, ...
15:54 < petertodd> ok, so lets come up with a concrete example: tx in block n spends an output that doesn't exist
15:55 < sipa> the witness will be required to contain a reference (for example, height) to the block that created the output, and an index into it the block (transaction number 5 in that block)
15:56 < petertodd> now, as a miner, why would I give a partial node that data? instead, knowing that'll instantly get turned into a fraud proof, I just don't distribute that part of the block, and instead create block n+1 that spends output in block n from tx A, where tx A simply isn't valid
15:56 < sipa> nobody will accept n+1 without seeing n
15:57 < petertodd> ah! but then, why do we need a fraud proof system? you just said no-one will accept n+1 without n, so fraud doesn't come into it
15:57 < petertodd> again, I'm just not seeing a concrete example where a fraud proof would ever be generated
15:57 < petertodd> ccccccducvnvnecvrblijvucvhtrgnudfblcnfukdkjt
15:57 < sipa> the fraud is needed so the partial node can be told its block n spends from an invalid output
15:57 < petertodd> lol, yubikey
15:57 < sipa> yeah, i agree with that
15:57 < petertodd> good thing that's one-time :)
15:57 < sipa> *fraud proof
15:58 -!- raedah [~raedah@172.56.38.34] has quit [Quit: Leaving]
15:58 < petertodd> right, and like I say, in an ecosystem with partial nodes, no miner making an invalid block would ever publish the parts of theirblocks that allow fraud to be proven, so the fraud proof itself is irrelevant
15:59 < sipa> that's like saying full nodes are irrelevant because no miner will produce a block that is invalid
15:59 < petertodd> it's pointless to do that - better to just setup a bunch of sybil's that prevent to SPV clients that everything is ok
15:59 < sipa> that's the point obviously
15:59 < petertodd> if everyone ran full nodes, then yes, that'd be irrelevant, but only on a tautological level :)
15:59 < sipa> it's the same thing
16:00 < petertodd> anyway, I'm arguing that what's important isn't the fraud proof, but rather the proof of correctness - take the fraud thing to it's logal conclusion
16:00 < petertodd> given that the existance of fraud proofs can be countered by making them impossible to generate, we need *another* level of protection, and that level of protection makes fraud proofs irrelevant
16:00 < sipa> *sigh*
16:01 < petertodd> note how in my scheme, a fraud proof is actually the *challenge*, which unless met with valid data is proof of fraud
16:01 < sipa> it's trivial to bypass that weakness by requiring all data committed to is revealed
16:01 < sipa> which means that partial nodes don't get a bandwidth reduction
16:01 < petertodd> I get that...
16:01 < petertodd> you're missing my point: whose using partial nodes?
16:02 < sipa> does that matter?
16:02 < petertodd> yes!
16:02 < sipa> anyone who likes to
16:02 < petertodd> if I'm a fraudulent miner, I'll sybil the network with a bunch of partial nodes that never give up fraud anyway
16:03 < petertodd> now, if my sybil isn't100% succesful, fraud proofs don't help, but validity challenges do
16:03 < sipa> if someone is able to sybil you, then yes, fraud proofs fail
16:04 < sipa> 00:53:14 < sipa> the assumption is that other nodes are either full, or do together validation for all txids whose hash starts with (not 0)
16:04 < sipa> 00:53:21 < petertodd> right
16:04 < kanzure> i am not sure that "reveal all the committed data" is the only way to solve this
16:04 < sipa> 00:53:25 < sipa> and that you're not censored from them
16:04 < sipa> oh, snarks can do it too :p
16:04 < petertodd> right, but in the non-100% succesful sysbil example, the best defence is the validity challenges, not pure fraud proofs, because the former is what lets me find out which nodes are lying to me
16:04 < petertodd> SNARKs can do anything; not interesting :)
16:05 < sipa> give me an example of a validity challenge?
16:05 < petertodd> so, in my simple merkletree example above, a validity challenge would be "I think leaf X in merkle tree Y is invalid, prove that it (locally) isn't"
16:06 < petertodd> if that validity challenge is unmet, it's a strong suggestion that there is fraud - if you have at least one peer that validated that part of the blockchain, when the challenge will be responded too with valid data
16:06 < kanzure> traditional fraud proof example is "here's two transactions that were committed to, and they are both spending the same inputs". the non-fraud proof version would be "show that this input is only used once" i guess?
16:07 < petertodd> kanzure: sure, but like I argued above, no-one would actually make a series of blocks where that can be proven and publish it, there's no point, resulting in the need for fraud challenges
16:07 < kanzure> well my message was an attempt to show a non-fraud proof variant of the same, but i think i failed :)
16:08 < petertodd> kanzure: yeah, the non-fraud proof would actually be to for a variety of nodes to challenge + respond to parts of the block(s) involved in that potential fraud, until there's a challenge that isn't extingished by valid data
16:08 < kanzure> "prove that there are no other inputs used" would require, as far as i can tell, something on the order of "send me all of your data"
16:09 < petertodd> kanzure: in that specific example, it'd be the part of the merkle tree leading to where the second spend of that output would be that'd fail to be met with valid data
16:09 < kanzure> why would you know where the second spend would be?
16:09 < petertodd> kanzure: only in a badly designed protocol :) a good protocol will have TXO commitments that let you prove validity of spending locally
16:10 < petertodd> kanzure: process of elimination
16:10 < kanzure> elimination sounds a lot like "send me all your data" except you might get lucky and bail early
16:10 < petertodd> kanzure: that should be telling... :)
16:10 < petertodd> kanzure: if you have a fraudulent peer, they're never going to send you a fraud proof, or the data that lets you generate one
16:11 < petertodd> kanzure: (which is why the whole idea is suspect anyway)
16:11 < kanzure> transaction commitments offer a proof of spending only once?
16:11 < kanzure> oh, transaction output commitments..
16:11 < petertodd> kanzure: note how my linearized tx history scheme redefines what fraud is to make double-spend fraud compactly provable (for a kinda terrible definition of 'compact')
16:12 < petertodd> kanzure: yeah
16:14 < kanzure> yes so i think that we can avoid the total bandwidth reduction that sipa was worried aobut above
16:15 < petertodd> what do you mean by "total bandwidth reduction"?
16:15 < sipa> anyway, i'm not planning on adding fraud proof support in the first version anyway; perhaps more discussion is needed - i'm just wary of changes that make compact fraud proofs less viable overall
16:16 < petertodd> sipa: sure, and the entire fraud proof vs. fraud challenge debate is orthogonal - an expensive fraud proof is an expensive validity proof
16:16 -!- Guyver2 [~Guyver2@a80-100-156-239.adsl.xs4all.nl] has quit [Read error: Connection reset by peer]
16:16 < petertodd> sipa: so convince me that a merkle tree of prev-block-contents is acceptable :)
16:24 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
16:26 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:26 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
16:27 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:27 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
16:27 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
16:32 < kanzure> petertodd: by "total bandwidth reduction" i meant "total bandwidth increase" heh. sipa was concerned about losing out on the bandwidth reduction benefits.
16:32 < sipa> kanzure: no
16:33 < sipa> kanzure: oh, you mean by committing to the prev block + witness?
16:33 < sipa> i will think more about that
16:34 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
16:37 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev]
16:38 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
16:58 < GitHub179> [bitcoin] dooglus opened pull request #7262: Reduce inefficiency of GetAccountAddress() (master...faster-getaccountaddress) https://github.com/bitcoin/bitcoin/pull/7262
17:02 -!- raedah [~raedah@172.56.38.34] has joined #bitcoin-core-dev
17:11 -!- Tera2342 [~Tera2342@223.207.233.83] has joined #bitcoin-core-dev
17:18 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has joined #bitcoin-core-dev
17:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ixhmdkwzlfrtqnnt] has quit [Quit: Connection closed for inactivity]
17:58 -!- zookolaptop [~user@68.233.157.2] has quit [Remote host closed the connection]
17:59 -!- zookolaptop [~user@68.233.157.2] has joined #bitcoin-core-dev
18:03 < morcos> sipa: petertodd: sometimes i find following these conversations over IRC very difficult.  But I have to say I mostly have many of the same thoughts as petertodd.  It's not really clear to me what situations we envision fraud proofs being actually used in.
18:04 < morcos> I wouldn't go as far as he has.  But I think its worth really carefully writing up the scenarios where we think they might be useful, so we know whats worth worrying about making compact and what isn't.  
18:04 < morcos> Also whether 4MB is compact or not is relevant to the situation in which these things might be used
18:05 < sipa> i gave one... whether you consider the additional assumptions (censorship resistance from other nodes that do validation of the parts you don't) to be a worthwhile outcome is something else :)
18:07 < morcos> sipa: so if you don't get the bandwidth reduction, then what exactly is a partial node saving?
18:08 < sipa> UTXO set maintenance, signature validation, ...
18:09 < morcos> so perhaps thats valuable during the bootstrapping phase?
18:10 < morcos> don't get me wrong, its not that i dont think these tools are of value, but trying to sketch out how we envision them actually being used is important
18:10 < sipa> fair enough, there is a lot of work left there
18:19 < phantomcircuit> morcos, signature validation from tip down, which is expensive to do without the fraud proofs
18:19 < phantomcircuit> (but which is largely incompatible with pruning)
18:21 -!- jayd3e [~jayd3e@207-181-211-167.c3-0.hnc-ubr1.chi-hnc.il.cable.rcn.com] has quit [Remote host closed the connection]
18:22 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds]
18:41 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-core-dev
18:56 -!- jayd3e [~jayd3e@207-181-211-167.c3-0.hnc-ubr1.chi-hnc.il.cable.rcn.com] has joined #bitcoin-core-dev
18:56 < jayd3e> so, I'm finding the bitcoin-core code pretty dense, it does a lot of things and is configured for a number of different platforms
18:58 < jayd3e> are all of the open threads for sending/receiving messages from other peers located in StartNode?
18:58 < jayd3e> in net.cpp
19:00 < sipa> there is 1 network thread (which sends/received between the network and CNode buffers) and one message habdling thread (which runs ProcessMessages and SendMessages in main.cpp)
19:00 < sipa> cfields is working on replacing a significant part of the network code with libevent
19:08 -!- Tera2342 [~Tera2342@223.207.233.83] has quit [Read error: Connection reset by peer]
19:08 < jayd3e> sipa: gotcha thanks
19:17 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:18 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Excess Flood]
19:21 < maaku> petertodd: I find any proposal that requires miners or worse hashing hardware to have full block data to be a dangerous regression over the segwit proposal
19:22 < petertodd> maaku: dangerous? I consider that to be a good thing
19:22 < maaku> right now transaction selection can be delegated to a third party, not so under your proposal I believe
19:22 < petertodd> maaku: yeah, you don'twant tx selection to be delegatable
19:23 < brg444> maaku is transaction selection delegation desirable?
19:23 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:24 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Read error: Connection reset by peer]
19:24 < maaku> petertodd: I strongly disagree. We don't live in an ideal world where every hashing hardware is running a full node.
19:24 < petertodd> maaku: I know, that's why I'm not proposing that yet
19:24 < maaku> having the hardware poll one source for coinbase rewards, and another for transaction selection would be an important incremental improvement over the current situation
19:25 < petertodd> maaku: I'm just proposing we ensure that mining pools have the data sufficient to validate
19:25 < maaku> something which is very much possible today but no one is doing
19:25 -!- JackH [~Jack@host-80-43-143-141.as13285.net] has quit [Ping timeout: 265 seconds]
19:25 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:25 < petertodd> maaku: why would that be an improvement?
19:26 < maaku> petertodd: transaction selection would no longer be confined to the same centralization pressures as mining hardware (power availability, distance from manufacturing, etc.)
19:26 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Remote host closed the connection]
19:27 < petertodd> maaku: are you assuming DRM tech?
19:27 < maaku> petertodd: ideally, yes, but it is still an improvement without
19:28 < maaku> we could have 100% hashpower in Shenzhen, but if it is smart property miners tied to transaction sources all over the world, with hundreds of orgs providing that data
19:28 -!- jayd3e [~jayd3e@207-181-211-167.c3-0.hnc-ubr1.chi-hnc.il.cable.rcn.com] has quit [Remote host closed the connection]
19:28 < petertodd> maaku: I think that's incredibly unrealistic - the guy with the power switch isn't going to delegate control like that
19:29 < petertodd> maaku: at best, the hashing power can be turned off by force
19:29 < petertodd> maaku: equally, I'm not very worried about that kind of centralization, as cheap power has diseconomies of scale
19:30 < maaku> petertodd: turning off the hashers is a risk under any scenario
19:30 < maaku> DRM just makes it the only thing he can do
19:30 < petertodd> maaku: DRM puts you in possitions where mfg's are encouraged to produce back doorable hardware
19:31 < maaku> petertodd: eh, cheapest power has diseconomies, but it's not like the whole globe evens out when your power usage goes up
19:31 < alpalp> .
19:31 < petertodd> "whole globe evens out"<- what do you mean by that?
19:32 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:32 < sipa> i would also be opposed to a system that requires full block access to anything that does not do the transaction selection
19:32 < petertodd> again, I think you're crazy and optimising for the wrong things
19:32 < sipa> but it seems like that may not be needed to combat the validationless mining degradation
19:32 < petertodd> maaku: ^^^ 
19:33 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Remote host closed the connection]
19:33 < sipa> so stop arguing
19:33 < petertodd> heh
19:33 < sipa> whether you agree or not is not relevant
19:34 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:35 < maaku> i'm not convinced we need to combat validationless mining, that's the issue :\
19:35 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Remote host closed the connection]
19:36 < petertodd> maaku: with segwit validationless mining is a significantly worse problem, as non-validating miners both have an advantage, yet can still collect tx fees
19:36 < sipa> maaku: or validationless transaction selection, if you will
19:37 < sipa> petertodd: of course, if there is trust, mining can always get pooling advantages by doing block construction in one central place for multiple pools
19:38 < petertodd> sipa: which we don't want
19:38 < sipa> agree
19:38 < sipa> but it may be inevitable...
19:39 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:39 < petertodd> sipa: so? why hasten it?
19:39 < sipa> i'm not arguing either way
19:39 < sipa> just observing
19:39 < petertodd> sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
19:40 < petertodd> keep in mind I'm designing for a system that's worth designing - other designs are possible, but solve "problems" that I'm not interested in solving (and frequently are simply bone headed stupid)
19:40 < sipa> no disagreement :)
19:41 < petertodd> if startinga new pool is ever difficult (assuming enough hashing power joins to keep variance reasonable) then we've failed and the system we have isn't bitcoin as we know it
19:41 < maaku> petertodd sipa: I'm aware that segwit makes non-validating mining easier to do. I'm not convinced that this is a problem, at least so much of a problem that we take actions which constrain the mining space
19:41 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Remote host closed the connection]
19:42 < petertodd> maaku: I'd judge my "nightmare scenario" in my dev list post to have >50% probability of happening - miners are pretty lazy in what they implement
19:42 < maaku> so far you guys are not arguing from first prinicples. rather i'm hearing a cached 'miners must have the data they need to validate!' without explaining why the cost is necessary
19:42 < petertodd> maaku: equally, I'd judge the probability of DRM hardware getting developed in the way you imagine as being <5%
19:43 < petertodd> maaku: currently the system assumes miners validate; if they stop validating we risk massive reorgs at best
19:43 < sipa> maaku: not just easier; it makes it more profitable and less observable too (by no longer being restricte to minkng empty blocks without validation)
19:43 < petertodd> maaku: heck, even in treechains you still need to force miners to actually have blockchain data for the system to work - bitcoin is at its core a proof-of-publication system, and the only thing forcing miners to publish right now is validation
19:44 -!- Alopex [~bitcoin@guru.dealing.ninja] has joined #bitcoin-core-dev
19:44 < petertodd> sipa: and validationless blocks with txs in them are much more dangerous
19:44 < sipa> petertodd: though, compared to downloading the full block right now and disabling script verification, there is not much difference
19:45 < sipa> petertodd: segwit just makes that use a constant factor less bandwidth
19:45 < petertodd> sipa: downloading the block is a huge bottleneck, and equally, the fact that everyone has to download it discourages the development of infrastructure where that isn't possible
19:45 < sipa> which may be an issue still
19:45 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
19:45 < petertodd> sipa: e.g. w/ segwit as described, we're guaranteed to get specialized relay networks that don't even propagate witness data at all
19:45 < dcousens> why does OP_CLTV care about the transactions lock time?
19:46 < dcousens> (when it just checks the stack item pushed just prior?)
19:46 < sipa> dcousens: ?
19:46 < petertodd> dcousens: CLTV checks the stack item against nLockTime
19:46 < sipa> dcousens: it compares that stack item with tx.nLocktime
19:47 < dcousens> Need to re-read that BIP then
19:47 < petertodd> dcousens: read the source
19:48 < sipa> petertodd: that is risky though... a miner could create a block with invalid witness data but not reveal that witness data, and not build on top himself, while his buddies all waste time on it
19:48 < petertodd> sipa: creating such a block costs 25BTC - it's a good bet that they won't
19:48 < petertodd> sipa: exactly like today...
19:48 < sipa> yup
19:48 < sipa> yup
19:51 < sipa> but that means that relying on such a relay network means you are trusting your buddies to a pretty significant degree
19:51 < sipa> same as with a relay network today
19:51 < sipa> if you don't fully validate
19:51 < petertodd> sipa: why? there's PoW proof that they're risking 25BTC, so the block is very probably valid
19:52 < petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
19:53 < dgenr8> petertodd: how low is "low enough"? 
19:53 < petertodd> and remember, if we don't constrain that form of mining now, it'll be much more difficult politically to constrain it in the future
19:53 < petertodd> dgenr8: huh?
19:53 < dgenr8> [15-12-28 19:39:52] <petertodd> sipa: the blocksize limit needs to be kept low enough to keep that from being a major problem; if the ecosystem wants to go elsewhere, I'm leaving bitcoin development, and so should the rest of you
19:54 < petertodd> dgenr8: I'm working on a document actually to set design criteria - a major one is the hashing power in adttendance at scaling bitcoin came to consensus that under attack conditions the orphan rates of largest and smallest pools should vary no more than +- 0.5%
19:55 < petertodd> dgenr8: that's a business requirement for there to be a level playing field
19:55 < dgenr8> do you know what that measurement is today?
19:56 < petertodd> dgenr8: no I don't, because we're not under attack conditions
19:56 < dgenr8> what are those? not just full blocks / spam?
19:57 < petertodd> dgenr8: miners who aren't cooperating with other miners is the big one
19:57 < dgenr8> not relaying others' blocks?
19:57 < petertodd> dgenr8: in fact, we're going to have to fix some exploits to be able to even meet that criteria with 1MB blocks, although at least fixing those exploits is easy
19:57 < petertodd> dgenr8: making blocks that contain not-previously-relayed (or recently relayed) transactions
19:58 < dgenr8> ah
19:58 < petertodd> dgenr8: basically, all the relay optimizations that work in the averge case can't be taken into account for that +-0.5% figure
19:59 < dgenr8> maybe the relay network should be turned off
19:59 < petertodd> dgenr8: there's no way to force people to do that
20:01 < phantomcircuit> <petertodd> sipa: how many delibrately invalid blocks have *ever* been created? I'm guessing zero in recent history
20:02 < phantomcircuit> petertodd, that's only true when mining is largely centralized
20:02 < petertodd> phantomcircuit: huh?
20:02 < phantomcircuit> petertodd, there's effectively a reputation system at work with mining today
20:03 < phantomcircuit> the stratum mining stuff is whitelist based
20:03 < petertodd> phantomcircuit: huh?
20:03 < petertodd> phantomcircuit: well yeah, I want to stay *at* the status quo, and not make things *worse*
20:03 < maaku> sipa: (re: pm) My point is that this is a spectrum not a binary choice. Things we'd close off is a hasher using an external transaction validation source but injecting its own transactions from a white list
20:03 < phantomcircuit> im saying that comparing mining off blocks w/o witness data validated isn't exactly comparable to the stratum mining that's happening today
20:03 < petertodd> phantomcircuit: I'd rather make things better, but that's probably politically/technically impooossible right now
20:04 < petertodd> phantomcircuit: the stratum stuff  has a strong disincentive to lying: if the other pools connect to you anonymously, you can't feed them bad data without hurting your own hashers
20:04 < phantomcircuit> petertodd, the problem is self correcting if mining becomes less centralized
20:05 < petertodd> phantomcircuit: why?
20:06 < phantomcircuit> petertodd, at least the stratum one does
20:06 < petertodd> phantomcircuit: I'm still not seeing your point
20:06 < phantomcircuit> reputation management is much more difficult with lots of players
20:06 < petertodd> phantomcircuit: this has nothing to do with reputation
20:07 < petertodd> phantomcircuit: (I mean, obviously it can, but stratum-using validationless mining works even if you don't trust the other guy, so long as you can connect to their pool anonymously)
20:09 < phantomcircuit> petertodd, there's an asynmetry between smaller and larger pools though
20:09 < petertodd> phantomcircuit: how so?
20:09 < phantomcircuit> a smaller miner can signal a nonsensical block with cost x * 25 while the larger miners cost is (x*2) * 25
20:10 < petertodd> phantomcircuit: sure, but you can weight that if you want, and it's still expensive
20:10 < petertodd> phantomcircuit: that also doesn't negate my segwit objections
20:11 < phantomcircuit> petertodd, maybe but the reasoning here isn't so simple
20:11 < petertodd> phantomcircuit: again, I'm simply preventing an ecosystem from developing where people regularly create blocks with txs in them w/o validating
20:14 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
20:21 < aj> phantomcircuit: hmm, back-of-the-envelope calculations seem to indicate it's never profitable for a miner to create fake blocks to trick SPV-miners to work on a bad chain (and it's only break-even if everyone else is SPV mining)
20:22 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Quit: Page closed]
20:23 < aj> phantomcircuit: (assuming: no external profits, eg shorting bitcoin on a different exchange; and the cost of creating a hash of an invalid block is the same as for a valid block -- if PoW was changed so you could produce a hash that simultaneously attested to a good and a bad block, that'd change)
20:36 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
20:37 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
20:38 -!- Tera2342 [~Tera2342@223.207.233.83] has joined #bitcoin-core-dev
20:38 -!- Tera2342 [~Tera2342@223.207.233.83] has quit [Read error: Connection reset by peer]
20:40 -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has quit [Read error: Connection reset by peer]
20:42 -!- alpalp [~alp@104-54-235-28.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev
21:03 -!- p15 [~p15@42.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
21:08 -!- Quent [~Quent@unaffiliated/quent] has quit [Read error: Connection reset by peer]
21:08 -!- Quent [~Quent@unaffiliated/quent] has joined #bitcoin-core-dev
21:24 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 43.0.1/20151216175450]]
21:25 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
22:01 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has quit [Ping timeout: 272 seconds]
22:01 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has joined #bitcoin-core-dev
22:35 -!- frankenmint [~frankenmi@75-175-72-226.ptld.qwest.net] has joined #bitcoin-core-dev
22:44 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has quit [Ping timeout: 260 seconds]
22:44 -!- smooth [~ubuntu@54.201.223.245] has joined #bitcoin-core-dev
22:44 -!- Yoghur114 [~Yoghurt11@131.224.198.111] has joined #bitcoin-core-dev
22:48 < dcousens> anyone know of an up to date reference for coinswap?
22:49 < dcousens> (or is https://bitcointalk.org/index.php?topic=321228.0 still considered the latest?)
22:52 < jcorgan> i don't think it ever made it to an implementation, and malleability would have broken it anyway.  of course, now, all these things deserve a second look.
22:53 < dcousens> I didn't necessarily mean impl, but, just in terms of an algorithm
22:54 < dcousens> Only curious because I'm currently playing with an algo. that might be more optimal, and just wondering if I could get some review over it
22:55 < jcorgan> probably a good -wizards discussion
22:55 < dcousens> ok
23:09 -!- zookolaptop [~user@68.233.157.2] has quit [Ping timeout: 256 seconds]
23:09 -!- tripleslash_b [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
23:09 -!- tripleslash_a [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 260 seconds]
23:34 -!- Alopex [~bitcoin@guru.dealing.ninja] has quit [Remote host closed the connection]
23:43 -!- mturquette [sid66043@gateway/web/irccloud.com/x-fywtttknjdnbxhrg] has joined #bitcoin-core-dev