sipa changed the topic of #bitcoin-wizards to: This channel is for discussing theoretical ideas with regard to cryptocurrencies, not about short-term Bitcoin development | http://bitcoin.ninja/ | This channel is logged. | For logs and more information, visit http://bitcoin.ninja
priidu has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 255 seconds]
bsm117532 has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 260 seconds]
abpa has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brg444 has joined #bitcoin-wizards
Ylbam has quit [Quit: Connection closed for inactivity]
smartcontracts has joined #bitcoin-wizards
NewLiberty has joined #bitcoin-wizards
kenshi84 has joined #bitcoin-wizards
CrazyLoaf has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 240 seconds]
brg444 has joined #bitcoin-wizards
c0rw1n has joined #bitcoin-wizards
priidu has quit [Ping timeout: 260 seconds]
rusty2 has joined #bitcoin-wizards
abpa has joined #bitcoin-wizards
brg444 has quit [Ping timeout: 248 seconds]
abpa has quit [Client Quit]
kenshi84 has quit [Quit: Leaving...]
laurentmt has joined #bitcoin-wizards
kenshi84 has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
priidu has joined #bitcoin-wizards
veleiro has joined #bitcoin-wizards
AaronvanW has quit []
brg444 has joined #bitcoin-wizards
adlai has quit [Ping timeout: 272 seconds]
btcdrak has quit [Quit: Connection closed for inactivity]
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
adlai has joined #bitcoin-wizards
edvorg has joined #bitcoin-wizards
priidu has quit [Remote host closed the connection]
ipwn has quit [Ping timeout: 245 seconds]
Chris_Stewart_5 has joined #bitcoin-wizards
ipwn has joined #bitcoin-wizards
ipwn has quit [Excess Flood]
ipwn has joined #bitcoin-wizards
windsok has quit [Ping timeout: 240 seconds]
lmacken has quit [Ping timeout: 252 seconds]
lmacken has joined #bitcoin-wizards
lmacken has joined #bitcoin-wizards
lmacken has quit [Changing host]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
windsok has joined #bitcoin-wizards
CrazyLoaf has quit [Quit: Connection closed for inactivity]
brg444 has quit [Quit: brg444]
Alopex has quit [Remote host closed the connection]
legogris has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
legogris has joined #bitcoin-wizards
brg444 has joined #bitcoin-wizards
andytosh1 is now known as andytoshi
pro has quit [Quit: Leaving]
Intensity has quit [Ping timeout: 256 seconds]
TheSeven has quit [Disconnected by services]
[7] has joined #bitcoin-wizards
Intensity has joined #bitcoin-wizards
Intensity has quit [Ping timeout: 256 seconds]
Intensity has joined #bitcoin-wizards
btcdrak has joined #bitcoin-wizards
kenshi84 has quit [Remote host closed the connection]
kenshi84 has joined #bitcoin-wizards
kenshi84 has quit [Ping timeout: 255 seconds]
edvorg has quit [Ping timeout: 240 seconds]
kankles has joined #bitcoin-wizards
kenshi84 has joined #bitcoin-wizards
Newyorkadam has joined #bitcoin-wizards
c0rw1n has quit [Quit: Leaving]
c0rw1n has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 240 seconds]
NewLiberty_ has joined #bitcoin-wizards
NewLiberty has quit [Ping timeout: 240 seconds]
NewLiberty has joined #bitcoin-wizards
NewLiberty_ has quit [Ping timeout: 240 seconds]
NewLiberty has quit [Ping timeout: 248 seconds]
NewLiberty has joined #bitcoin-wizards
Alopex has quit [Remote host closed the connection]
veleiro has quit [Remote host closed the connection]
Alopex has joined #bitcoin-wizards
chjj has quit [Ping timeout: 245 seconds]
chjj has joined #bitcoin-wizards
Ylbam has joined #bitcoin-wizards
jtimon has joined #bitcoin-wizards
jtimon has quit [Ping timeout: 240 seconds]
mountaingoat has quit [Ping timeout: 248 seconds]
mountaingoat has joined #bitcoin-wizards
Burrito has joined #bitcoin-wizards
Davasny has joined #bitcoin-wizards
dnaleor has quit [Ping timeout: 255 seconds]
mountaingoat has quit [Ping timeout: 240 seconds]
dnaleor has joined #bitcoin-wizards
mountaingoat has joined #bitcoin-wizards
chjj has quit [Ping timeout: 240 seconds]
_whitelogger has joined #bitcoin-wizards
_rht has joined #bitcoin-wizards
moctos_ has joined #bitcoin-wizards
chjj has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has joined #bitcoin-wizards
AaronvanW has quit [Changing host]
pro has joined #bitcoin-wizards
Newyorkadam has quit [Quit: Newyorkadam]
q4 has joined #bitcoin-wizards
_rht has quit [Quit: Connection closed for inactivity]
Guyver2 has joined #bitcoin-wizards
q4 has quit [Ping timeout: 255 seconds]
priidu has joined #bitcoin-wizards
laurentmt has joined #bitcoin-wizards
laurentmt has quit [Client Quit]
maker has left #bitcoin-wizards ["= """]
jtimon has joined #bitcoin-wizards
Chris_Stewart_5 has joined #bitcoin-wizards
hashtag has quit [Ping timeout: 240 seconds]
hashtag has joined #bitcoin-wizards
windsok has quit [Ping timeout: 240 seconds]
tromp__ has quit [Ping timeout: 256 seconds]
hashtag has quit [Ping timeout: 240 seconds]
hashtag has joined #bitcoin-wizards
Guyver2 has quit [Quit: :)]
spinza has quit [Quit: Coyote finally caught up with me...]
laurentmt has joined #bitcoin-wizards
windsok has joined #bitcoin-wizards
windsok has quit [Ping timeout: 255 seconds]
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<Jaamg>
any good academic papers on the role of max block size?
d9b4bef9 has quit [Remote host closed the connection]
<Jaamg>
perhaps from the system dynamics/game theory perspective
<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.
<gmaxwell>
decntrlzr: that paper makes a known invalid assumption that block propagation time depends on size. There is no fundimental reason that it should.
<gmaxwell>
"that the larger a block, the longer it takes for it to be spread in the Bitcoin network and reach consensus"
<decntrlzr>
Which paper? I referenced two.
<gmaxwell>
The first, haven't looked at the second yet.
<decntrlzr>
Wait a second, are you saying that all else being equal, large blocks typically don't take longer to propagate than small blocks?
<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.
<decntrlzr>
That sounds obviously false. Communicating more information should take longer. And on average, would not larger blocks often contain more information?
<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.
Guyver2 has joined #bitcoin-wizards
<gmaxwell>
decntrlzr: the block isn't sent when blocks are found (even today).
<gmaxwell>
because almost all the information in the block is already known to all nodes.
<decntrlzr>
Sure, but both Houy and Rizun's models are based on propagating blocks similar to the way they are done now.
<gmaxwell>
decntrlzr: blocks are _now_ propagated without sending the block data! (and have been for years for the bulk of propagation)
<decntrlzr>
And I'm pretty sure I've seen graphs that prove the larger blocks do take longer to propagate.
<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)
<decntrlzr>
Amiller: do you agree with gmaxwell that the size of the block has nothing to do with propagation time?
<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.
<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)
<gmaxwell>
And we know that at the limit there doesn't need to be any relationship between size and delay at all.
<decntrlzr>
This seems pretty good evidence that larger blocks are more likely to be orphaned.
<gmaxwell>
The commonly used protocols now have some slightly connection, e.g. relay protocol sends two bytes per transaction used.
<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.
<gmaxwell>
decntrlzr: ignores correlating effects -- e.g. miners that produced big blocks but didn't use fast relay protocols.
<decntrlzr>
In fact, I think Ledger had a paper on this too.
<gmaxwell>
decntrlzr: no, because the transactions that go into blocks can be arbritarily delayed.
<decntrlzr>
Let me find the paper....
<gmaxwell>
for example I am about to synchronise 100GB of data to you in under a second. 0000000000000000023ae016f87c04623937b18add7f1fc9b8e92db156a00514
<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.
<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)
<gmaxwell>
I was originally on the editoral team and quit when I realized how unethical the management was. :(
<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).
<decntrlzr>
Found it. It's the subchains paper. The idea is to use weak blocks to come to a sort of pre-consensus.
<decntrlzr>
But the point the author makes in Section 5 is that it still takes time to communicate the _new_ information.
<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".
<gmaxwell>
Yes, and it's simply wrong.
<gmaxwell>
Because the author had a specifc publically articulated interest in convincing people of this delay claim, when it simply isn't true.
<decntrlzr>
What's wrong with it? Seemed pretty convincing to me (but so did Rizun's other paper).
<gmaxwell>
:(
<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.
<decntrlzr>
Right.
<decntrlzr>
That's why orphaning risk remains.
<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.
<gmaxwell>
and if you have a block solution you simply don't relay those txn.
<gmaxwell>
so a transaction is only attempted for a block if it's already well propagated.
<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.
<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.
<gmaxwell>
decntrlzr: Thats like saying all miners should sleep(blocksize) before transmitting their blocks. Its not incentive compatible.
<gmaxwell>
In fact it is _precisely_ the same argument.
<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.
<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.
<decntrlzr>
Unless they agree to your (different) protocol.
<gmaxwell>
No no.
<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).
<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.
<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.
<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.
<gmaxwell>
and if orphaning is controlling size it must be very large -- so a huge incentive to do so.
<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.
<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.
<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.
<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.
<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.
<gmaxwell>
decntrlzr: yes? and? that doesn't constrain the size of anything.
<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)
<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.
<decntrlzr>
Maybe you should write a rebuttal and really layout your thoughts clearly, using equations and graphs too.
moctos_ has quit [Ping timeout: 245 seconds]
<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.
<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.
<gmaxwell>
it's such transparently dishonest poltical bullshit.
<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.
<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.
<gmaxwell>
::shrugs::
<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.
<decntrlzr>
Anyways, I feel I've struck a nerve. Sorry if I've offended you in anyway.
<gmaxwell>
decntrlzr: you haven't, don't worry about that.
<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.
<gmaxwell>
I do agree that Peter R's writing _looks_ impressive, but so far it's just been wrong.
<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.
<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)
<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)
<decntrlzr>
Do you have evidence that Rizun was funded to write his "orphaning controls size" paper?
<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.
<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"
<gmaxwell>
decntrlzr: yes, go see the review commentary.
<gmaxwell>
I filed a formal complaint with ledger and got that much added.
<gmaxwell>
Which Peter R tried to deny but couldn't refute the email evidence. :(
<gmaxwell>
I shouldn't have to do shit like that.
moli_ has joined #bitcoin-wizards
<gmaxwell>
you really should read that email chain that I linked to. It's quite interesting.
<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."
<decntrlzr>
And his subchains paper effectively argues that, IMO.
<kanzure>
so does decntrlzr disagree about delayed transactions?
<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.
<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)
<decntrlzr>
It _is_ related to the size, because the new information is related to the transaction rate, which is related to the size.
<gmaxwell>
::sigh:: please read more carefully, in whats described in that email no such correspondance exists.
<gmaxwell>
A found block never has any new information with it except the nonce.
<gmaxwell>
meaning the size is the same if the rate is 1tx/s or 10000tx/s.
<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.
<decntrlzr>
It gives people the chance to write rebuttals, from which we can advance our understanding.
arthurb has joined #bitcoin-wizards
<gmaxwell>
No rebuttal will ever get published.
<gmaxwell>
You'll all just be more ignorant as a result of funded position pieces being laundered through a fake academic journal.
<gmaxwell>
Sad.
<gmaxwell>
but your problem, not mine. :)
decntrlzr has quit [Quit: Page closed]
<gmaxwell>
Cheers.
<kanzure>
is there a good reason for anyone to assume that miners are mining not-widely-known transactions? where is that one coming from?
<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).
* gmaxwell
gets numbers.
<kanzure>
like is it some kind of assumption about out-of-band transaction submission to miners?
<uiuc-slack1>
<amiller> i'd love to see some study of the effectiveness of the bitcoin relay backbones
<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...
<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
<gmaxwell>
amiller: apparently you need to use chrome for matt's stats.
<kanzure>
i thought there was a relay study, one sec
<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
<gmaxwell>
amiller: 0.12.
<kanzure>
hmm can't remember the name. difficult task. maybe it was a scalingbitcoin.org presentation..
<gmaxwell>
we decreased latencies in block validation and create new block about 30x...
<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
<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
<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.
<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.
<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)
<kanzure>
nope; maybe there is no publication that gives relay network models. oh well.
<kanzure>
(i was thinking of a scalingbitcoin.org paper or something, but i don't see one)
<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. :)
Burrito has quit [Quit: Leaving]
<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.
<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
<gmaxwell>
it's a big concept and somewhat counterintutive.
<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)
<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.
<gmaxwell>
schemes like set reconcillation could be more efficient in theory, but they're computationally slow. :(
rusty2 has joined #bitcoin-wizards
handle_ has joined #bitcoin-wizards
handle_ is now known as celso
celso is now known as celsosz
celsosz is now known as celsosouza
d9b4bef9 has quit [Remote host closed the connection]
d9b4bef9 has joined #bitcoin-wizards
rusty2 has quit [Ping timeout: 240 seconds]
mmeijeri has joined #bitcoin-wizards
<mmeijeri>
test
<mmeijeri>
@gmaxwell: can you explain where the need for committing to txs in a weak block comes from? other than in the merkle root
celsosouza has quit [Remote host closed the connection]
Davasny has quit [Remote host closed the connection]
<Eliel_>
mmeijeri: it's a way to communicate the set of transactions that's actually being mined in practise.
<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.
<Eliel_>
*so they aren't included
<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.
<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.