-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/11/13, 21:31 , Peter Todd wrote:
>> Final conclusions is that the fee currently is too small and that
>> there is no need to keep a maximum block size, the fork
>> probability will automatically provide an incentive to not let
>> block grows into
> Final conclusions is that the fee currently is too small and that there
> is no need to keep a maximum block size, the fork probability will
> automatically provide an incentive to not let block grows into infinity.
Your definition of P_fork is inaccurate for a miner with non-negligable
hashing
(Talking about the paper, not the BIP). With regard to racing the other
winner which catches up when private pool length=1:
i) the model does not appear to take into account that when another pool
goes on to mine a block, and the attacker publishes their selfishly-withheld
block, the selfish pool
Hey Peter, something seems wrong with your above analysis: I think a miner
would withhold his block not because it leads to a greater probability of
winning the next one, but because it increases his expected revenue.
Suppose a cabal with fraction q of the total hashing power is n blocks
ahead on
Once the ASIC race calms down because everyone has one, has more or less
optimal power supplies, process improvements aren't easily reachable
anymore etc then I'd expect people to dissipate from the large pools
because eliminating their fees will become the next lowest hanging fruit to
squeeze out
Mike, Pieter,
My writeup outlines a framework for good approximation to a minimal fee
as well as the optimal block size. The model has basically just one
parameter, the propagation time - if that goes down, so can the fee.
(Well there is another parameter too, the time btw blocks, which
currently
I think trying to help miners figure out the propagation/fees tradeoff at
the moment is a non-starter until we understand it better ourselves. A
server that tracks and records block propagation times, how many fees per
passed up per block, orphan stats per size bucket etc would be tremendously
help
Correcting myself:
On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille wrote:
> I believe that C. Decker's paper used measurements for propagation
> delays for blocks 18-19, which happened between may and juli
> 2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
They did use d
Hi,
(I didn't have time to read your e-mail entirely yet, I'll do so later)
I believe that C. Decker's paper used measurements for propagation
delays for blocks 18-19, which happened between may and juli
2012. The latest bitcoind/bitcoin-qt release at the time was 0.6.3.
I'm sure the gen
Following the discussion on the recent mining sybil trick, I reread the
article on block propagation by Decker et al.* and decided to use it for
doing a proper estimate of transaction fee size and optimal block size.
The propagation of a block depends on and is roughly proportional to its
size. Fu
On Thu, Nov 07, 2013 at 02:56:56PM +1000, Gavin Andresen wrote:
> > P.S: If any large pools want to try this stuff out, give me a shout. You
> > have my PGP key - confidentiality assured.
> >
>
> If I find out one of the large pools decides to run this 'experiment' on
> the main network, I will ma
On Wed, Nov 06, 2013 at 10:59:28PM -0600, Kyle Jerviss wrote:
> 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 somewh
I wonder if you need to take into consideration the fact that there might
be another "bad" pool (in the 1-Q part of the network) running the same
strategy and also holding on to two blocks of their own? Once they find
their third block before you do, then your 2 blocks lead is gone instantly.
--
13 matches
Mail list logo
