On 8/1/2015 1:45 PM, Pieter Wuille via bitcoin-dev wrote:
>
> Regarding "reasonable", I have a theory. What if we would have had 8
> MB blocks from the start? My guess is that some more people would have
> decided to run their high-transaction-rate use cases on chain, that
> we'd regularly see 4-6
On Sat, Aug 1, 2015 at 10:22 PM, John T. Winslow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Regarding the block size increase, at least conceptually it seems to me
> there should be an easy solution. If we look at what works well with
> bitcoin, for example the block reward
On Fri, Jul 31, 2015 at 10:39 AM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is a summary of the proposals in my previous mail at
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
> 1. Initiation: BIP34 style voting, with support of
Regarding the block size increase, at least conceptually it seems to me
there should be an easy solution. If we look at what works well with
bitcoin, for example the block reward halving and difficulty regimes
which due to their step function nature both contribute to the stability
and predicta
Although the chance is very slim, it is possible to have multiple
hardforks sharing the same flag block. For example, different proposals
may decide the flag time based on voting result and 2 proposals may have
the same flag time just by chance. The coinbase message is to preclude
any potential
>> Ok, so set the bit and then include BIP-GIT-HASH of the canonical BIP on
>> github in the coinbase?
>
>
> I guess the git hash is not known until the code is written? (correct me if
> I'm wrong) As the coinbase message is consensus-critical, it must be part of
> the source code and therefore you
On 1 August 2015 at 01:17, Gregory Maxwell wrote:
> One can quite easily transact in a way to intentionally produce such a
> split to seperate the existance of your coins onto the seperate forks;
> just as anyone would need to do to perform a reorg-and-respend attack
> on a single blockchain.
>
