Kyle Jerviss [ARCHIVE] on Nostr: š Original date posted:2013-11-07 š Original message:Each block that you solve ...
š
Original date posted:2013-11-07
š Original message:Each block that you solve has a reward. In practice, some blocks will
be orphaned, so the expected reward is slightly less than the nominal
reward. Each second that you delay publishing a block, the expected
reward drops somewhat.
On an infinite timeline, the total reward approaches the expected
reward. But reality is discrete, and zero tends to be a brick wall. If
you delay publishing a block, you will get either the nominal reward, or
zero, not some fraction in between. And if your personal random walk
involves an excursion through negative land, you may not stick around
long enough for it to come back.
Thus, a positive expected value is not sufficient for some strategy to
be a good one.
Peter Todd wrote:
> On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
>> You are ignoring the gambler's ruin. We do not operate on an
>> infinite timeline. If you find a big pool willing to try this,
>> please give me enough advance warning to get my popcorn ready.
> Gamblers ruin has nothing to do with it.
>
> At every point you want to evaluate the chance the other side will get
> ahead, vs. cashing in by just publishing the blocks you have. (or some
> of them) I didn't mention it in the analysis, but obviously you want to
> keep track of how much the blocks you haven't published are worth to
> you, and consider publishing some or all of your lead to the rest of the
> network if you stand to lose more than you gain.
>
> Right now it's a mostly theoretical attack because the inflation subsidy
> is enormous and fees don't matter, but once fees do start to matter
> things get a lot more complex. An extreme example is announce/commit
> sacrifices to mining fees: if I'm at block n+1, the rest of the network
> is at block n, and there's a 100BTC sacrifice at block n+2, I could
> easily be in a situation where I have zero incentive to publish my block
> to keep everyone else behind me, and just hope I find block n+2. If I
> do, great! I'll immediately publish to lock-in my winnings and start
> working on block n+3
>
>
> Anyway, my covert suggestion that pools contact me was more to hopefully
> strike fear into the people mining at a large pool and get them to
> switch to a small one. :) If everyone mined solo or on p2pool none of
> this stuff would matter much... but we can't force them too yet.
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131106/31419fb3/attachment.html>;
š Original message:Each block that you solve has a reward. In practice, some blocks will
be orphaned, so the expected reward is slightly less than the nominal
reward. Each second that you delay publishing a block, the expected
reward drops somewhat.
On an infinite timeline, the total reward approaches the expected
reward. But reality is discrete, and zero tends to be a brick wall. If
you delay publishing a block, you will get either the nominal reward, or
zero, not some fraction in between. And if your personal random walk
involves an excursion through negative land, you may not stick around
long enough for it to come back.
Thus, a positive expected value is not sufficient for some strategy to
be a good one.
Peter Todd wrote:
> On Wed, Nov 06, 2013 at 10:15:40PM -0600, Kyle Jerviss wrote:
>> You are ignoring the gambler's ruin. We do not operate on an
>> infinite timeline. If you find a big pool willing to try this,
>> please give me enough advance warning to get my popcorn ready.
> Gamblers ruin has nothing to do with it.
>
> At every point you want to evaluate the chance the other side will get
> ahead, vs. cashing in by just publishing the blocks you have. (or some
> of them) I didn't mention it in the analysis, but obviously you want to
> keep track of how much the blocks you haven't published are worth to
> you, and consider publishing some or all of your lead to the rest of the
> network if you stand to lose more than you gain.
>
> Right now it's a mostly theoretical attack because the inflation subsidy
> is enormous and fees don't matter, but once fees do start to matter
> things get a lot more complex. An extreme example is announce/commit
> sacrifices to mining fees: if I'm at block n+1, the rest of the network
> is at block n, and there's a 100BTC sacrifice at block n+2, I could
> easily be in a situation where I have zero incentive to publish my block
> to keep everyone else behind me, and just hope I find block n+2. If I
> do, great! I'll immediately publish to lock-in my winnings and start
> working on block n+3
>
>
> Anyway, my covert suggestion that pools contact me was more to hopefully
> strike fear into the people mining at a large pool and get them to
> switch to a small one. :) If everyone mined solo or on p2pool none of
> this stuff would matter much... but we can't force them too yet.
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131106/31419fb3/attachment.html>;