On Mon, May 22, 2017 at 03:05:49AM -0400, Russell O'Connor via bitcoin-dev
wrote:
> Not all of the inputs to the SHA256 compression function are created
> equal. Only the second argument, the chunk data, is applied to the SHA256
> expander. `merkleRoot` is designed to ensure that the first argum
On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
> > why?
>
> the main
> issue is due to 0.13.1+ having many segwit related features active
> already, including all the P2P components, the new network service
> flag, the witness-tx and block messages, compact blocks v2 and
> preferenti
On Mon, May 22, 2017 at 05:30:46PM +0200, Paul Sztorc wrote:
> Surprisingly, this requirement (or, more precisely, this incentive) does
> not effect miners relative to each other. The incentive to upgrade is only
> for the purpose of preventing a "theft" -- defined as: an improper
> withdrawal from
On Sun, May 28, 2017 at 3:51 PM, Tom Zander via bitcoin-dev
wrote:
> On Saturday, 27 May 2017 01:09:10 CEST James Hilliard wrote:
>> > why?
>>
>> the main
>> issue is due to 0.13.1+ having many segwit related features active
>> already, including all the P2P components, the new network service
>>
This proposal is written under the assumption that the signatories to the
Consensus 2017 Scaling Agreement[1] are genuinely committed to the terms of the
agreement, and intend to enact the updates described therein. As such,
criticisms pertaining to the chosen deployment timeline or hard fork up
Seems to me an obvious use case for drive chains are to have high speed
small transactions on a side chain, eventually cleared to the main chain.
Not sure why miners would want this to fail any more than any other side
chain, like Liquid or lightning.
On May 28, 2017 5:23 PM, "Peter Todd via bi
