Kalle Rosenbaum [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-28 📝 Original message:2015-09-27 21:50 GMT+02:00 ...
📅 Original date posted:2015-09-28
📝 Original message:2015-09-27 21:50 GMT+02:00 Gregory Maxwell <gmaxwell at gmail.com>:
> On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I was mansplaining weak blocks to my wife. She asked a simple question:
> >
> > Why would I, as a miner, publish a weak block if I find one?
> >
> > I don't know.
> > Sure, I will get faster propagation for my solved block, should I find
> one.
> > On the other hand everybody else mining a similar block will enjoy the
> same
> > benefit. Assuming that I'm not a huge miner, it's unlikely that I will
> > actually solve the block, so I'm probably just giving away fast
> propagation
> > times to someone else.
> > So how does publishing a weak block benefit the producer of it more than
> the
> > other miners? Please help me understand this.
>
> Keep in mind, because of efficient differential transmission the cost
> to you is effectively nothing if your transaction acceptance policy is
> predictable, it's a hand-full of bytes sent. And by failing to send
> yours you do little to nothing to deny others the improvement.
>
>
Suppose that you've solved a block Z (weak or not) and you want to
propagate it using a previous weak block Y. With "efficient differential
transmission", I assume that you refer to the transmission of the
differences between Y and Z to a peer? What encodings are discussed? I
guess IBLTs are a hot candidate, but are there other schemes in the making?
I suppose that sending something like "weak block Y plus transactions A, B,
C minus transaction ids h(D), h(E)" is not considered an efficient
differential transmission. Then that's part of the answer to my question.
> Lets imagine an alternative weak-blockless weak block implementation:
>
> Every N seconds, every miner send to every other miner what they're
> working on. This isn't totally crazy-- efficient differential
> transmission will keep the amount transmitted small.
>
> Any block found can be referenced to any of these earlier worklists.
>
> What the effect be of not transmitting yours?
>
> If your block is unlike everyone elses, you would suffer great delays
> in the event you found a block.
> If your block is mostly like everyone elses, you wouldn't suffer as
> much delay-- but the transmission costs would be negligible in that
> case. ... the size sent is proportional to the improvement you get
> when finding a block.
>
"the size sent is proportional to the improvement you get when finding a
block." - This encapsulates the issue quite well! The more exotic block I'm
building, the more I would benefit from publishing a weak block, but my
weak block would also be larger.
>
> In either case, no one else is harmed by you not sending yours... they
> still send their lists.
>
> A problem with that scheme is that unless you've layered an identity
> based access control system on it anyone can DOS attack it, because
> anyone can send as much as they want, they don't even have to be
> actual miners.
>
> What weak blocks adds to that is using hashcash as a rate limiting
> mechanism-- a coordination free lottery weighed by hash-power decides
> who can transmit.
>
> What if you don't participate in the lottery and share your solutions?
> No major harm for the other users... the other users will just choose
> a somewhat lower weak-block threshold to get the updates at the
> desired rate than they would otherwise. To the extent that what you
> were working on was different from anyone else, you'll suffer because
> you failed to make use of your chance to influence what could be
> efficiently transmitted to include your own blocks.
>
Makes perfect sense. Also, if I'm working on an exotic block, the
probability of someone extending my weak block would be low-ish, so I'm not
necessarily "giving away fast propagation times to someone else" as I first
thought.
> You could also ask a question of why would you transitively relay
> someone elses announcement-- well if it helped their blocks too (by
> reflecting things they also want to mine) the answer is obvious. But
> what if it was disjoint from the things they wanted to mine and didn't
> help compared to the weak blocks they already relayed? In that case
> it's still in likely in their interest to relay it because if a block
> similar to it is produced and they extend that block they may end up
> orphaned because of propagation delays their parent block suffered.
> What if they receive an announcement which is so "ugly" that they
> wouldn't extend the chain with the strong block version of it (they'd
> intentionally try to fork it off?)-- in that case they wouldn't want
> to relay it. So much the same logic as why you relay other parties
> blocks applies, including-- relaying helps the network, but if you
> don't it'll still get along fine without you.
>
Thank you very much for your explanation.
/Kalle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/50ae758a/attachment.html>;
📝 Original message:2015-09-27 21:50 GMT+02:00 Gregory Maxwell <gmaxwell at gmail.com>:
> On Sun, Sep 27, 2015 at 3:10 PM, Kalle Rosenbaum via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I was mansplaining weak blocks to my wife. She asked a simple question:
> >
> > Why would I, as a miner, publish a weak block if I find one?
> >
> > I don't know.
> > Sure, I will get faster propagation for my solved block, should I find
> one.
> > On the other hand everybody else mining a similar block will enjoy the
> same
> > benefit. Assuming that I'm not a huge miner, it's unlikely that I will
> > actually solve the block, so I'm probably just giving away fast
> propagation
> > times to someone else.
> > So how does publishing a weak block benefit the producer of it more than
> the
> > other miners? Please help me understand this.
>
> Keep in mind, because of efficient differential transmission the cost
> to you is effectively nothing if your transaction acceptance policy is
> predictable, it's a hand-full of bytes sent. And by failing to send
> yours you do little to nothing to deny others the improvement.
>
>
Suppose that you've solved a block Z (weak or not) and you want to
propagate it using a previous weak block Y. With "efficient differential
transmission", I assume that you refer to the transmission of the
differences between Y and Z to a peer? What encodings are discussed? I
guess IBLTs are a hot candidate, but are there other schemes in the making?
I suppose that sending something like "weak block Y plus transactions A, B,
C minus transaction ids h(D), h(E)" is not considered an efficient
differential transmission. Then that's part of the answer to my question.
> Lets imagine an alternative weak-blockless weak block implementation:
>
> Every N seconds, every miner send to every other miner what they're
> working on. This isn't totally crazy-- efficient differential
> transmission will keep the amount transmitted small.
>
> Any block found can be referenced to any of these earlier worklists.
>
> What the effect be of not transmitting yours?
>
> If your block is unlike everyone elses, you would suffer great delays
> in the event you found a block.
> If your block is mostly like everyone elses, you wouldn't suffer as
> much delay-- but the transmission costs would be negligible in that
> case. ... the size sent is proportional to the improvement you get
> when finding a block.
>
"the size sent is proportional to the improvement you get when finding a
block." - This encapsulates the issue quite well! The more exotic block I'm
building, the more I would benefit from publishing a weak block, but my
weak block would also be larger.
>
> In either case, no one else is harmed by you not sending yours... they
> still send their lists.
>
> A problem with that scheme is that unless you've layered an identity
> based access control system on it anyone can DOS attack it, because
> anyone can send as much as they want, they don't even have to be
> actual miners.
>
> What weak blocks adds to that is using hashcash as a rate limiting
> mechanism-- a coordination free lottery weighed by hash-power decides
> who can transmit.
>
> What if you don't participate in the lottery and share your solutions?
> No major harm for the other users... the other users will just choose
> a somewhat lower weak-block threshold to get the updates at the
> desired rate than they would otherwise. To the extent that what you
> were working on was different from anyone else, you'll suffer because
> you failed to make use of your chance to influence what could be
> efficiently transmitted to include your own blocks.
>
Makes perfect sense. Also, if I'm working on an exotic block, the
probability of someone extending my weak block would be low-ish, so I'm not
necessarily "giving away fast propagation times to someone else" as I first
thought.
> You could also ask a question of why would you transitively relay
> someone elses announcement-- well if it helped their blocks too (by
> reflecting things they also want to mine) the answer is obvious. But
> what if it was disjoint from the things they wanted to mine and didn't
> help compared to the weak blocks they already relayed? In that case
> it's still in likely in their interest to relay it because if a block
> similar to it is produced and they extend that block they may end up
> orphaned because of propagation delays their parent block suffered.
> What if they receive an announcement which is so "ugly" that they
> wouldn't extend the chain with the strong block version of it (they'd
> intentionally try to fork it off?)-- in that case they wouldn't want
> to relay it. So much the same logic as why you relay other parties
> blocks applies, including-- relaying helps the network, but if you
> don't it'll still get along fine without you.
>
Thank you very much for your explanation.
/Kalle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/50ae758a/attachment.html>;