--- Log opened Sat Jan 14 00:00:04 2017
00:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:03 -!- veleiro [~veleiro@fsf/member/veleiro] has quit [Remote host closed the connection]
00:04 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
00:08 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 245 seconds]
00:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-wizards
00:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xopygmmlmhwnapzh] has joined #bitcoin-wizards
00:38 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
00:53 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]
01:23 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has quit [Ping timeout: 248 seconds]
01:37 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has joined #bitcoin-wizards
01:40 -!- Burrito [~Burrito@unaffiliated/burrito] has joined #bitcoin-wizards
01:50 -!- Davasny [~quassel@78.10.231.191] has joined #bitcoin-wizards
02:00 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has quit [Ping timeout: 255 seconds]
02:04 -!- mountaingoat [~mountaing@gateway/vpn/privateinternetaccess/mountaingoat] has quit [Ping timeout: 240 seconds]
02:13 -!- dnaleor [~dnaleor@78-23-74-78.access.telenet.be] has joined #bitcoin-wizards
02:22 -!- mountaingoat [~mountaing@unaffiliated/mountaingoat] has joined #bitcoin-wizards
03:31 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 240 seconds]
03:42 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has quit [Remote host closed the connection]
03:43 -!- _whitelogger [~whitelogg@uruz.whitequark.org] has joined #bitcoin-wizards
03:48 -!- _rht [uid86914@gateway/web/irccloud.com/x-qyachweyvojswoik] has joined #bitcoin-wizards
03:54 -!- moctos_ [~anthonyya@172.98.67.76] has joined #bitcoin-wizards
03:55 -!- chjj [~chjj@c-50-152-196-52.hsd1.ca.comcast.net] has joined #bitcoin-wizards
04:06 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has joined #bitcoin-wizards
04:06 -!- AaronvanW [~AaronvanW@207pc74.sshunet.nl] has quit [Changing host]
04:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-wizards
05:07 -!- pro [~pro@unaffiliated/pro] has joined #bitcoin-wizards
05:11 -!- Newyorkadam [~Newyorkad@wikipedia/Newyorkadam] has quit [Quit: Newyorkadam]
05:37 -!- q4 [~q4@user-94-254-173-50.play-internet.pl] has joined #bitcoin-wizards
05:56 -!- _rht [uid86914@gateway/web/irccloud.com/x-qyachweyvojswoik] has quit [Quit: Connection closed for inactivity]
06:02 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
06:23 -!- q4 [~q4@user-94-254-173-50.play-internet.pl] has quit [Ping timeout: 255 seconds]
06:28 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
06:30 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
06:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
06:31 -!- maker [~maker@unaffiliated/maker] has left #bitcoin-wizards ["= """]
06:34 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-wizards
06:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
06:49 -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 240 seconds]
06:51 -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards
07:00 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 240 seconds]
07:01 -!- tromp__ [~tromp@rtc35-025.rentec.com] has quit [Ping timeout: 256 seconds]
07:06 -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has quit [Ping timeout: 240 seconds]
07:07 -!- hashtag [~hashtagg_@cpe-174-97-254-80.ma.res.rr.com] has joined #bitcoin-wizards
07:16 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
07:16 -!- spinza [~spin@196.212.164.26] has quit [Quit: Coyote finally caught up with me...]
07:18 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
07:28 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-wizards
07:33 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 255 seconds]
08:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
08:06 < Jaamg> any good academic papers on the role of max block size?
08:07 < Jaamg> perhaps from the system dynamics/game theory perspective
08:07 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
08:08 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards
08:08 < kanzure> Jaamg: http://diyhpl.us/~bryan/papers2/bitcoin/
08:11 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-wizards
08:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-wizards
08:13 < Jaamg> kanzure: thanks, good resource
08:16 -!- tromp__ [~tromp@rtc35-026.rentec.com] has joined #bitcoin-wizards
08:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
08:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
08:32 -!- moctos_ [~anthonyya@172.98.67.76] has quit [Ping timeout: 248 seconds]
08:44 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
08:45 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
08:47 -!- moctos_ [~anthonyya@208.167.254.229] has joined #bitcoin-wizards
09:15 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
09:21 -!- c0rw1n [~c0rw1n@64.36-244-81.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 245 seconds]
09:22 -!- c0rw1n [~c0rw1n@91.181.3.176] has joined #bitcoin-wizards
09:23 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
10:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-wizards
10:36 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 245 seconds]
10:55 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
11:09 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-wizards
11:14 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-wizards
11:31 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
11:36 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 258 seconds]
12:01 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has joined #bitcoin-wizards
12:31 -!- henrytill [~henrytill@unaffiliated/henrytill] has quit [Remote host closed the connection]
12:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
12:44 -!- decntrlzr [6031c40e@gateway/web/freenode/ip.96.49.196.14] has joined #bitcoin-wizards
12:48 < decntrlzr> @Jaamg: here's a great paper by a PhD economist that uses game theory to show how the size of blocks depends on the offered fee rate: http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/13/59
12:49 < decntrlzr> This work assumes the block size limit is significantly higher than the average block size.
12:51 < decntrlzr> Here's another great paper on the topic of the transaction fee market when the block size limit is above demand: https://www.bitcoinunlimited.info/resources/feemarket.pdf
12:52 < decntrlzr> I find the math in this one easier to follow.  Nicolas Houy actually compares Rizun's model with his own model in Section 5 of "The Bitcoin Mining Game" paper.
12:53 < uiuc-slack1> <amiller> http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/13/40  here's the open review document for the first article, in case you want to see what kind of review and criticism in got during the peer review process
13:05 < gmaxwell> decntrlzr: that paper makes a known invalid assumption that block propagation time depends on size. There is no fundimental reason that it should.
13:05 < gmaxwell> "that the larger a block, the longer it takes for it to be spread in the Bitcoin network and reach consensus"
13:05 < decntrlzr> Which paper?  I referenced two.
13:06 < gmaxwell> The first, haven't looked at the second yet.
13:07 < decntrlzr> Wait a second, are you saying that all else being equal, large blocks typically don't take longer to propagate than small blocks?
13:07 < gmaxwell> But in the first that assumption is no more true than if they were assuming all miners were adding a sleep(blocksize) to their work. In the sense that yes they could do that, but it would be irrational for them to do so, and they could simply stop.
13:07 < decntrlzr> That sounds obviously false.  Communicating more information should take longer.  And on average, would not larger blocks often contain more information?
13:08 < gmaxwell> decntrlzr: correct. Propagation time has no reason to have any tim related to the blocksize, because the only _new_ information at the time of solving is the nonce that was found and who found it.
13:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-wizards
13:08 < gmaxwell> decntrlzr: the block isn't sent when blocks are found (even today).
13:08 < gmaxwell> because almost all the information in the block is already known to all nodes.
13:09 < decntrlzr> Sure, but both Houy and Rizun's models are based on propagating blocks similar to the way they are done now.
13:09 < gmaxwell> decntrlzr: blocks are _now_ propagated without sending the block data! (and have been for years for the bulk of propagation)
13:09 < decntrlzr> And I'm pretty sure I've seen graphs that prove the larger blocks do take longer to propagate.
13:10 < uiuc-slack1> <amiller> not really decentrlzr, for a long time now miners have been using optimized relays like bitcoin backbone relay and now fibre (and falcon)
13:10 < decntrlzr> Amiller: do you agree with gmaxwell that the size of the block has nothing to do with propagation time?
13:10 < gmaxwell> decntrlzr: and while already more efficient mechenisms are used, for the question of system incentives and economics, the question isn't what people already do but what they _could_ do.
13:12 < gmaxwell> (all of those analysis assume that basically orphan rate is driving miner decisions which creates huge incentives to use the most efficient protocols possible; as well as big benefits for centeralizing into larger pools until the most efficient protocol is used)
13:12 < gmaxwell> And we know that at the limit there doesn't need to be any relationship between size and delay at all.
13:12 < decntrlzr> OK I found one of the graphs I had seen before: http://imgur.com/ctZOdO7
13:13 < decntrlzr> This seems pretty good evidence that larger blocks are more likely to be orphaned.
13:13 < gmaxwell> The commonly used protocols now have some slightly connection, e.g. relay protocol sends two bytes per transaction used.
13:14 < decntrlzr> gmaxwell, even if just the _new_ information needs to be communicate, if the transaction rate is higher, then there will typically be _more_ new information to be communicated.
13:14 < gmaxwell> decntrlzr: ignores correlating effects -- e.g. miners that produced big blocks but didn't use fast relay protocols.
13:14 < decntrlzr> In fact, I think Ledger had a paper on this too.
13:15 < gmaxwell> decntrlzr: no, because the transactions that go into blocks can be arbritarily delayed.
13:15 < decntrlzr> Let me find the paper....
13:16 < gmaxwell> for example I am about to synchronise 100GB of data to you in under a second. 0000000000000000023ae016f87c04623937b18add7f1fc9b8e92db156a00514
13:17 < gmaxwell> decntrlzr: unfortunately, ledger isn't a credible venue with effective review. It's mostly a vanity press for Peter R. who is a dishonest plagerist.
13:17 < gmaxwell> And then a number of other authors who have been taken along for a ride, in part because it's hard to get bitcoin related articles into other venues (something ledger was supposted to resolve)
13:18 < gmaxwell> I was originally on the editoral team and quit when I realized how unethical the management was. :(
13:19 < gmaxwell> decntrlzr: the paper you're looking from presents a design which I originally sent in private to the author, and hobbled it to intentionally leave some delay relationship. But the hobbling is needless and would be ignored by economically rational partiticpants. (and its removal cannot be prevented).
13:20 < decntrlzr> Found it.  It's the subchains paper.  The idea is to use weak blocks to come to a sort of pre-consensus.
13:20 < decntrlzr> But the point the author makes in Section 5 is that it still takes time to communicate the _new_ information.
13:20 < decntrlzr> http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/40/55
13:21 < gmaxwell> basically it presumes miners use near solutions to establish the content of blocks in advance,  but assumes the the only way to add to the content is to add it without pre-propagation, taking a risk of orphaning.  But thats stupid, "don't do that".
13:21 < gmaxwell> Yes, and it's simply wrong.
13:21 < gmaxwell> Because the author had a specifc publically articulated interest in convincing people of this delay claim, when it simply isn't true.
13:21 < decntrlzr> What's wrong with it?  Seemed pretty convincing to me (but so did Rizun's other paper).
13:21 < gmaxwell> :(
13:22 < gmaxwell> decntrlzr: Simple. In that scheme you add a transaction to the queue of to-be-included by _attempting_ to include it. Right?  so if you do actually solve a block you'll be exposed to orphaning.
13:22 < decntrlzr> Right.
13:23 < decntrlzr> That's why orphaning risk remains.
13:23 < gmaxwell> So now instead of doing that, when you attempt to mine a block simple include a hash commitment to the set of transaction's you'd like to include (e.g. in a coinbase op_return)  and when you get a weak solution-- you relay the stransactions in that extra list.
13:23 < gmaxwell> and if you have a block solution you simply don't relay those txn.
13:23 < gmaxwell> so a transaction is only attempted for a block if it's already well propagated.
13:24 < decntrlzr> But that would be a different protocol.  It wouldn't be subchains.  If the majority of the miners did follow the subchains protocol, then that wouldn't happen.
13:24 < gmaxwell> And if you imagine that the scheme in the paper were deployed, and the rate of adding transactions was causing orphaning (thus limiting things) miners could just start adding that extra commitment, and no one could stop them, and they'd have less orphaning, and so everyone would be forced to go along with them or lose money.
13:25 < gmaxwell> decntrlzr: Thats like saying all miners should sleep(blocksize) before transmitting their blocks. Its not incentive compatible.
13:25 < gmaxwell> In fact it is _precisely_ the same argument.
13:26 < gmaxwell> that basically you can insert a delay for no reason that any miner can simply skip amonst themselves, and enjoy lower orphaning, and no one can stop them, and its still compatible with everyone else.
13:26 < decntrlzr> That's not true though.  You have to communicate the full block contents _somehow_ to the other miners.  If you just publish hashes, the other miners won't know how to interpret them.
13:27 < decntrlzr> Unless they agree to your (different) protocol.
13:27 < gmaxwell> No no.
13:27 < gmaxwell> (as an aside, all these equlibrium papers require subsidy which is also something bitcoin won't have forever unless it's made inflationary; but thats an aside).
13:28 < decntrlzr> Yes yes.  The other miners need to be able to figure out the precise contents of the solved block.  So the information does need to be communicated.
13:28 < gmaxwell> decntrlzr: say you and I are miners. in a subchains world. there is some equlibrium at an orphaning rate of 5%.  Both of us start adding these intention commitments, and our income will increase _massively_ compared to other miners, even if they hate us.
13:29 < gmaxwell> so it's just like having miners inserts sleeps related to size on the blocks they recieve.  "honest miners" can keep doing it, but rational miners will cut it out and enjoy lower orphaning as a result.
13:30 < gmaxwell> and if orphaning is controlling size it must be very large -- so a huge incentive to do so.
13:31 < decntrlzr> Yes, I agree.  But Rizun adressed that.  Miners can use tighter and tighter subchaining to reduce their orphaning risk.  Only you and I may do it at first, but like you said, the other miners will join in to increase their profits.
13:31 < gmaxwell> decntrlzr: worse, I describe this protocol of precommitments to rizun in a extensive private email review of his first paper; where he vigorously argued against it.  then he turned around and published a hobbled version of the same design under his own name, and didn't even bother discussing the hobbling.
13:32 < gmaxwell> the point that he misses is that you don't need more subchaining, you just commit in advance and orphaning rate is rendered completely independant. A very simple change.
13:34 < gmaxwell> email thread here: http://pastebin.com/jFgkk8M3
13:34 < decntrlzr> I actually think it's you that is missing something.  If you commit to a set of transactions in advance, and some new high-fee transactions come in, then you can't include those new TXs without increasing your orphan risk.
13:35 < decntrlzr> So there will be some fee rate for those new transactions that make it worthwhile to _not_ use your precommittments and accept the added orphan risk.
13:35 < gmaxwell> decntrlzr: yes? and?  that doesn't constrain the size of anything.
13:35 < uiuc-slack1> <amiller> http://www.ledgerjournal.org/ojs/index.php/ledger/article/view/40/47 here is the transcript of the peer review process that the subchains paper went through
13:36 < gmaxwell> (and not using the precommitment can add much more than the delay of the additional marginal transaction.  e.g. with isotropic fees I believe, without careful analysis, that a new transaction can never beat the precommitment)
13:37 < decntrlzr> From my perspective as someone reading up on this topic, I see three well-written articles with equations and charts that all make sense to me.  Perhaps the models used are simplified and imperfect, but that's how models are.
13:37 < decntrlzr> Maybe you should write a rebuttal and really layout your thoughts clearly, using equations and graphs too.
13:38 -!- moctos_ [~anthonyya@208.167.254.229] has quit [Ping timeout: 245 seconds]
13:38 < gmaxwell> Why? I can't afford to match the well funded fud rizun keeps spinning.  At the end of the day it's simply incorrect, and if people want to decieve themselves, and go along with outright fraud and plagerism, they're welcome to do so.
13:38 < gmaxwell> amiller: you mean where it managed to attribute subchains to Gavin when all gavin was doing was mentioning a conversation he had with myself and Rusty at scaling bitcoin mtl about my email to Rizun?  shame on all of you.
13:39 < gmaxwell> it's such transparently dishonest poltical bullshit.
13:39 < gmaxwell> decntrlzr: as you saw with his prior paper which loudly argued (as he also did in response to my email review) that better was _information theoretically impossible_ ... and then he went on to write a paper about the counter argument I sent him.
13:40 < gmaxwell> So perhaps now in another six months he'll write another paper calling subchains wrong for the reason pointed out here, but then argue that some relationship still remains for the reason you mention.
13:40 < gmaxwell> ::shrugs::
13:41 < decntrlzr> I don't think he argued that at all.  What he argued was that it takes a non-zero amount of time to communicate a non-zero amount of information.
13:41 < decntrlzr> Anyways, I feel I've struck a nerve.  Sorry if I've offended you in anyway.
13:42 < gmaxwell> decntrlzr: you haven't, don't worry about that.
13:42 < gmaxwell> I am irritated about it, because I think it's really unfortunate to miseducate people and it'll cause a generation of bad scholarship because people are basically funding intentionally decieving people for political ends.
13:43 < gmaxwell> I do agree that Peter R's writing _looks_ impressive, but so far it's just been wrong.
13:44 < gmaxwell> And instead of handling the errors in a way that would improve human understanding they've been handled in a way narrowly tailored to serve the political purposes which he is being paid to service.
13:45 < gmaxwell> (the original, admitted by him now to be incorrect, orphaning controls size paper was funded by undisclosed patrons; and when it was oblittered by review he attempted to take credit for the scheme described to him in that review, but then limited it needlessly, and didn't mention doing that-- bad form, and it hurts to waste my life dealing with misunderstandings like these)
13:48 < gmaxwell> (consider how your own understanding has evolved during this discussion... you started off arguing that that original paper's assumption would hold; thats the kind of misunderstanding this fosters, and the kind of misunderstanding Bitcoin could live or die based on people getting it)
13:48 < decntrlzr> Do you have evidence that Rizun was funded to write his "orphaning controls size" paper?
13:49 < gmaxwell> decntrlzr: yes, it's discussed in the gold collapsing thread, Peter R posted a paragraph version of the argument then cypherdoc said that he and others were interested in funding an elaboration.
13:49 < decntrlzr> And by the way, in case you missed it, he thanks you in his subchains paper: "He also acknowledges Gregory Maxwell for motivating him to investigate fee market dynamics in scenarios where information is pre- propagated"
13:50 < gmaxwell> decntrlzr: yes, go see the review commentary.
13:50 < gmaxwell> I filed a formal complaint with ledger and got that much added.
13:50 < gmaxwell> Which Peter R tried to deny but couldn't refute the email evidence. :(
13:51 < gmaxwell> I shouldn't have to do shit like that.
13:51 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-wizards
13:52 < gmaxwell> you really should read that email chain that I linked to. It's quite interesting.
13:53 < decntrlzr> Still not seeing it gmaxwell.  I did look at that email chain after you posted and it looks like Rizun was being polite while standing his ground that the fee market based on orphan risk would hold in the case of "pre-consensus."
13:53 < decntrlzr> And his subchains paper effectively argues that, IMO.
13:53 < kanzure> so does decntrlzr disagree about delayed transactions?
13:54 < gmaxwell> decntrlzr: Really? what makes you think that? He continues repeating the untrue claim that the orphaning risk must be related to the _size_. Which you know to be untrue. He never argues in that thread that it's related to the rate.
13:54 < gmaxwell> (which if he did I would have pointed out that the rate also didn't hold, because the scheme described there didn't take risk for rate)
13:55 < decntrlzr> It _is_ related to the size, because the new information is related to the transaction rate, which is related to the size.
13:55 < gmaxwell> ::sigh:: please read more carefully, in whats described in that email no such correspondance exists.
13:55 < gmaxwell> A found block never has any new information with it except the nonce.
13:56 < gmaxwell> meaning the size is the same if the rate is 1tx/s or 10000tx/s.
13:56 < decntrlzr> Anyways, this is obviously a hot topic and I don't want to argue any longer.  But I do think we should applaud people for taking the time to lay out their ideas clear, like Rizun and Houy have done.
13:56 < decntrlzr> It gives people the chance to write rebuttals, from which we can advance our understanding.
13:57 -!- arthurb [~arthurb@2601:647:4100:fec6:18:6f93:9f0c:f2be] has joined #bitcoin-wizards
13:57 < gmaxwell> No rebuttal will ever get published.
13:57 < gmaxwell> You'll all just be more ignorant as a result of funded position pieces being laundered through a fake academic journal.
13:57 < gmaxwell> Sad.
13:57 < gmaxwell> but your problem, not mine. :)
13:58 -!- decntrlzr [6031c40e@gateway/web/freenode/ip.96.49.196.14] has quit [Quit: Page closed]
13:58 < gmaxwell> Cheers.
13:58 < kanzure> is there a good reason for anyone to assume that miners are mining not-widely-known transactions? where is that one coming from?
13:59 < gmaxwell> kanzure: no, I mean it's clearly untrue. Even under just BIP152 propagation, which isn't an especially heroic effort (like real preconsensus would be).
13:59  * gmaxwell gets numbers.
13:59 < kanzure> like is it some kind of assumption about out-of-band transaction submission to miners?
14:00 < uiuc-slack1> <amiller> i'd love to see some study of the effectiveness of the bitcoin relay backbones
14:00 < gmaxwell> all these equlibrium papers make a number of weird assumptions; that there is perpetual subsidy that is non-negligible, that miners won't centeralize, etc...
14:00 < uiuc-slack1> <amiller> there are a lot of statistics on display at the page but it's slow on my browser and i'm not sure what to take from them
14:00 < gmaxwell> amiller: apparently you need to use chrome for matt's stats.
14:00 < kanzure> i thought there was a relay study, one sec
14:01 < uiuc-slack1> <amiller> i like the chart on blockchain.info w/ orphan blocks, beuase it shows it cutting in half sharply in like jan 2016 but idont know what that corresponds to
14:01 < gmaxwell> amiller: 0.12.
14:01 < kanzure> hmm can't remember the name. difficult task. maybe it was a scalingbitcoin.org presentation..
14:01 < gmaxwell> we decreased latencies in block validation and create new block about 30x...
14:01 < uiuc-slack1> <amiller> ah.  also i had never heard your hpothesiss before about how the orphan rate corresponding with large blocks, may correspond just to miners that don't use that relay format or something
14:02 < uiuc-slack1> <amiller> it should be posible to show that orphan blocks corrleate with the size of transactions that have not been pre-propagated through fibre, but if you control for those, then there is no remaining effect on delay
14:03 < gmaxwell> amiller: fibre doesn't really depend that much on pretransmission ... in practice, in the real world the big source of delays is round trip times. And fiber unconditionally has none.
14:04 < uiuc-slack1> <amiller> hmmm
14:05 < gmaxwell> kanzure: in the last 144 blocks here is the histrogram of missing BIP152 transaction counts for my node at home. https://0bin.net/paste/ctfl2bBCDGOEP6px#Gjmz7yLxz3yo7xbDyoRVV2CEppFC1gVMj9c-27Vi1TM
14:05 < gmaxwell> amiller: there is a graph on that page for reconstruction delay vs data used in reconstruction so you can see there is some, but it's pretty small compared to the 200ms or whatever that blocks take to just go around the world at the speed of light.
14:06 < gmaxwell> (if I weren't afraid to load the page I'd tell you the graph number, its the one with red and blue dots)
14:08 < uiuc-slack1> <amiller> kanzure, i bet you're thinking of rusty's tests? https://rustyrussell.github.io/pettycoin/2014/11/05/Playing-with-invertible-bloom-lookup-tables-and-bitcoin-transactions.html
14:08 < kanzure> nope; maybe there is no publication that gives relay network models. oh well.
14:09 < kanzure> (i was thinking of a scalingbitcoin.org paper or something, but i don't see one)
14:09 < gmaxwell> kanzure: it's moot in any case, like the preconsensus insight is that you don't have to depend on what might have been forwarded well, you can use the preconsensus to be ~sure of it. :)
14:10 -!- Burrito [~Burrito@unaffiliated/burrito] has quit [Quit: Leaving]
14:10 < gmaxwell> amiller: you know how fibre works right? it does something like BIP152 but then streams FEC to fill in the missing data, and uses a nearly optimal but _very fast_ long block FEC.
14:10 < kanzure> i agree with you that i already have the data that can be used to verify your blockhash 0000000000000000023ae016f87c04623937b18add7f1fc9b8e92db156a00514 but i'm not sure readers are going to grok that example
14:11 < gmaxwell> it's a big concept and somewhat counterintutive.
14:12 < kanzure> (they will just see the "100 GB in an instant" claim and laugh claiming that "no two people could possibly transfer 100 GB/sec even if they agreed about the contents of the data!" as if agreement was impossible)
14:13 < gmaxwell> amiller: so fibre is unconditionally just  one-way delay + time to serialize the BIP152 sketch + time to seralize the needed fec, and packets swarm between peers, so transmission between peers is shared and no packet needs to be sent twice by the source.
14:13 < gmaxwell> schemes like set reconcillation could be more efficient in theory, but they're computationally slow. :(
14:23 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has joined #bitcoin-wizards
14:40 -!- handle_ [~handle@2804:14c:658f:4dc7:788a:36ed:a2a1:5436] has joined #bitcoin-wizards
14:42 -!- handle_ is now known as celso
14:43 -!- celso is now known as celsosz
14:47 -!- celsosz is now known as celsosouza
15:03 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
15:04 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-wizards
15:09 -!- rusty2 [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
15:16 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has joined #bitcoin-wizards
15:16 < mmeijeri> test
15:17 < mmeijeri> @gmaxwell: can you explain where the need for committing to txs in a weak block comes from? other than in the merkle root
15:35 -!- celsosouza [~handle@2804:14c:658f:4dc7:788a:36ed:a2a1:5436] has quit [Remote host closed the connection]
15:41 -!- Davasny [~quassel@78.10.231.191] has quit [Remote host closed the connection]
15:47 < Eliel_> mmeijeri: it's a way to communicate the set of transactions that's actually being mined in practise.
15:50 < Eliel_> and when you do that so that they included in the actual block, should you find one, you avoid risking higher orphaning rates to do so.
15:50 < Eliel_> *so they aren't included
15:52 < Eliel_> once the txs have enough weak confirmations through the commitments, you know the orphaning risk in including them to the actual block is very low and will include them in the actual block.
15:55 < Eliel_> the actual merkle root would work pretty well for the same purpose, considering it's extremely unlikely to find a real block, but you can reduce the orphaning risk a little more by waiting until you have evidence others also have those transactions.
15:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
16:04 < Eliel_> If all you had was the real merkle tree to communicate which transactions you're mining, you'd avoid adding a lot of transactions at once to manage your orphaning risk. However, with a commitment outside the merkle tree, you can just dump all transactions in there that you have since it doesn't affect the orphaning risk.
16:06 < Eliel_> so, basically, having that option improves the theoretical capacity of the system.
16:10 -!- Andrew23 [Andrew23@86.121.87.237] has joined #bitcoin-wizards
16:12 < mmeijeri> ah ok, that makes sense
16:12 < mmeijeri> it's a bit similar to Ripple's consensus mechanism
16:14 < Eliel_> mmeijeri: kind of, but it only forms a very weak consensus. It's enough in this case since every miner has strong incentives to conform.
16:25 < Eliel_> it's funny how at first glance it might seem miners have an incentive to hoard transactions to themselves so they can grab the fees for them but this kind of turns that on it's head.
16:27 < Eliel_> Although, miners still have that incentive for very high fee transactions though. But at the same time, that disincentivizes users from using high enough fees for that to happen.
17:13 -!- Andrew23 [Andrew23@86.121.87.237] has quit [Changing host]
17:13 -!- Andrew23 [Andrew23@unaffiliated/andreiuk] has joined #bitcoin-wizards
17:20 -!- Andrew23 [Andrew23@unaffiliated/andreiuk] has quit []
17:21 -!- Andrew23 [Andrew23@86.121.87.237] has joined #bitcoin-wizards
17:21 -!- Andrew23 [Andrew23@86.121.87.237] has quit [Changing host]
17:21 -!- Andrew23 [Andrew23@unaffiliated/andreiuk] has joined #bitcoin-wizards
17:29 -!- Andrew23 is now known as Andreiuk2
17:35 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
17:39 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
17:42 < petertodd> IIRC the compact proof-of-hashing power (aka proof-of-proof-of-work) stuff had issues with variance; anyone have a link to that issue?
17:43 < uiuc-slack1> <amiller> petertodd, the proof-of-proof-of-work tidily fixes all the problems with variance, you should look at this if you haven't http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf
17:43 < petertodd> amiller: thanks, looking at that now
17:44 < petertodd> amiller: am I correct in saying the variance issue is because we need to prove that the blocks are actually interconnected; IE, does the variance issue not apply to standard fiat-shamir type stuff?
17:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-xopygmmlmhwnapzh] has quit [Quit: Connection closed for inactivity]
17:47 < uiuc-slack1> <amiller> so the fiat shamir thing is like, you claim you have a block chain that is 450000 blocks long, so you pick a random sample of k blocks, and you're confident with high probability that you have at *least* 440000 blocks or so
17:48 < petertodd> amiller: right, but what you didn't prove is that the 440,000 blocks actually formed a chain
17:48 < uiuc-slack1> <amiller> but since many of those are also in common with the honest chain, that doesn't help so much
17:49 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-wizards
17:49 < petertodd> amiller: ah right, so actually we've got two issues
17:50 < petertodd> amiller: in any case, I'm askin the question because I'm writing up a proof-of-coins thing, and wanted to make sure the variance issue *didn't* apply to it
17:51 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Ping timeout: 240 seconds]
17:51 -!- PRab_ is now known as PRab
17:52 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
17:52 < petertodd> amiller: though I noticed for that, we do have a "doublespend" issue - the merkle tree needs to be a ordered mapping by coin id, or else you can reuse coins in the proof - kinda obvious, but I didn't see that mentioned in the writeups I looked at
17:54 -!- [ANDREI] [Andreiuk@gateway/shell/elitebnc/x-lttbywymvacigpod] has joined #bitcoin-wizards
17:57 -!- Andreiuk2 [Andrew23@unaffiliated/andreiuk] has left #bitcoin-wizards []
18:18 -!- atgreen [~green@CPE10da438ecb59-CM00fc8d24cab0.cpe.net.cable.rogers.com] has joined #bitcoin-wizards
18:38 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
18:41 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
18:44 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
18:49 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
18:55 -!- mmeijeri [3efb099d@gateway/web/freenode/ip.62.251.9.157] has quit [Quit: Page closed]
19:00 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
19:01 -!- celsosouza [~celso@2804:14c:658f:4dc7:788a:36ed:a2a1:5436] has joined #bitcoin-wizards
19:02 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
19:07 -!- priidu [~priidu@unaffiliated/priidu] has quit [Ping timeout: 240 seconds]
19:12 -!- NewLiberty [~NewLibert@107-142-8-22.lightspeed.irvnca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
19:15 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
19:18 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
19:20 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
19:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:22 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
19:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
19:23 -!- priidu [~priidu@unaffiliated/priidu] has joined #bitcoin-wizards
19:23 -!- priidu [~priidu@unaffiliated/priidu] has quit [Remote host closed the connection]
19:27 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:f089:98fe:3142:54c6] has joined #bitcoin-wizards
19:30 -!- thom [xD@ring0.se] has quit [Ping timeout: 240 seconds]
19:31 -!- thom [xD@ring0.se] has joined #bitcoin-wizards
19:52 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 240 seconds]
20:04 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:f089:98fe:3142:54c6] has quit [Ping timeout: 255 seconds]
20:04 -!- Noldorin [~noldorin@unaffiliated/noldorin] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz...]
20:15 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-wizards
20:22 -!- celsosouza [~celso@2804:14c:658f:4dc7:788a:36ed:a2a1:5436] has quit [Remote host closed the connection]
20:22 -!- xissburg_ [~xissburg@unaffiliated/xissburg] has quit [Quit: leaving]
20:34 -!- shesek [~shesek@bzq-84-110-55-167.red.bezeqint.net] has joined #bitcoin-wizards
20:49 -!- pro [~pro@unaffiliated/pro] has quit [Quit: Leaving]
21:00 -!- legogris [~legogris@128.199.205.238] has quit [Remote host closed the connection]
21:01 -!- legogris [~legogris@128.199.205.238] has joined #bitcoin-wizards
21:15 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Quit: Later.]
21:25 -!- [7] [~quassel@rockbox/developer/TheSeven] has quit [Ping timeout: 256 seconds]
21:25 -!- TheSeven [~quassel@rockbox/developer/TheSeven] has joined #bitcoin-wizards
21:47 -!- anon616 [~nobody@ec2-52-207-226-93.compute-1.amazonaws.com] has quit [Remote host closed the connection]
21:49 -!- anon616 [~nobody@ec2-52-207-226-93.compute-1.amazonaws.com] has joined #bitcoin-wizards
22:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
23:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:09 -!- NewLiberty [~NewLibert@2602:306:b8e0:8160:f089:98fe:3142:54c6] has joined #bitcoin-wizards
23:09 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
23:11 -!- Aranjedeath [~Aranjedea@unaffiliated/aranjedeath] has quit [Quit: Three sheets to the wind]
23:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:28 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-wizards
23:48 -!- irc88 [~irc88@192.77.237.167] has quit [Ping timeout: 240 seconds]
--- Log closed Sun Jan 15 00:00:05 2017