On Mon, Apr 21, 2014 at 01:30:28AM +, Jonathan Levin wrote:
CC'ing bitcoin-research - may be more appropriate to move the discussion
there as this discussion is delving into future scenarios.
Hi all,
I am a post-graduate economist writing a paper on the incentives of mining.
Even
Jonathan -
These are a few things I've been wishing for recent data on:
- 95th percentile transaction propagation time vs. fees/kb, vs. total fees
- Count of blocks bypassing well-propagated transactions vs. fees/kb,
vs. total fees
- Signed-double-spend confirmation probability vs.
On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org wrote:
Of course, in reality smaller miners can just mine on top of block headers
and include no transactions and do no validation, but that is extremely
harmful to the security of Bitcoin.
I don't think it reduces security much.
I'm not convinced that headers first will result in miners hashing on
top of the block with more work without knowing if it's valid yet
instead of just keep hashing on top of the longest known-to-be-valid
chain.
Both options are risky for the miner in some way, and I guess the
probability of
On 04/21/2014 11:40 AM, Ashley Holman wrote:
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd p...@petertodd.org
mailto:p...@petertodd.org wrote:
That is mistaken: you can't mine on top of just a block header,
leaving small miners disadvantaged as they are earning no profit
while they
That wasn't what I was saying. Right now the primacy of a block is
determined by the time at which the `block` message is received, which
is delays due to both the time it takes to transmit the block data and
the time it takes to validate. Headers-first, on the other hand, has the
option of basing
: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Economics of information propagation
That wasn't what I was saying. Right now the primacy of a block is
determined by the time at which the `block` message is received, which
is delays due to both the time it takes
Pieter tried it already. If the two nodes views of each others mempools are
not exactly in alignment it ends up being slower than just sending the data
immediately and redundantly.
On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach m...@monetize.io wrote:
Yes, it certainly can be improved in
Thank you for your thoughts.
The earlier, larger block A will only become stale if *two* blocks are
found in the extra time it takes for block A to propagate the network.
That is a substantially different risk, and probably a negligible
concern to most miners.
I really like Mark’s
Hi all,
I am a post-graduate economist writing a paper on the incentives of mining.
Even though this issue has been debated in the forums, I think it is important
to get a sense of the magnitude of the incentives at play and determine what
implications this has for the transaction fee market.
As soon as we switch to headers
first - which will be soon - there will be no difference in propagation
time no matter how large the block is. Only 80 bites will be required to
propagate the block header which establishes priority for when the block is
fully validated.
On Apr 20, 2014 6:56 PM,
Of course, in reality smaller miners can just mine on top of block headers
and include no transactions and do no validation, but that is extremely
harmful to the security of Bitcoin.
If it's only during the few seconds that it takes to to verify the block,
then would this really be that big
12 matches
Mail list logo
