Re: [bitcoin-dev] Three hardfork-related BIPs

Comment on #1. You're dropping the blocksize limit to 300KB and only reaching the limit that we have in place today 7 years later? We're already at capacity today, surely you're not serious with this proposal? When you promised code for a hard forking block size increase in the HK agreement I

Re: [bitcoin-dev] Three hardfork-related BIPs

I can’t recommend your first 2 proposals. But I only have the time to talk about the first one for now. There are 2 different views on this topic: 1. “The block size is too small and people can’t buy a coffee with an on-chain transaction. Let’s just remove the limit” 2. “The block size is too

Re: [bitcoin-dev] Three hardfork-related BIPs

On Friday, January 27, 2017 3:04:50 AM Andrew Johnson wrote: > Comment on #1. You're dropping the blocksize limit to 300KB and only > reaching the limit that we have in place today 7 years later? The limit only drops all the way to 300k if it activates before 2017 April. Considering that this

[bitcoin-dev] Three hardfork-related BIPs

I've put together three hardfork-related BIPs. This is parallel to the ongoing research into the MMHF/SHF WIP BIP, which might still be best long-term. 1) The first is a block size limit protocol change. It also addresses three criticisms of segwit: 1) segwit increases the block size limit

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Excuse me, yes, for previously-signed transactions this is required. We might consider some limits on UTXO-chain-from-before-the-fork-length and likely something like move towards only allowing one transaction per block from the old mode over time. I highly disagree that compatibility with

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

Even more to the point, new post- fork coins are fork-specific. The longer both forks persist, the more transactions become unavoidably fork-specific through the mixing in of these coins. Any attempt to maximize replay will become less effective with time. The rationality of actors in this

Re: [bitcoin-dev] Changing the transaction version number to be varint

> On 20 Jan 2017, at 22:02, Tom Zander via bitcoin-dev > wrote: > > The way to do this is that from a certain block-height the current > transaction format labels bytes 2, 3 & 4 to be unused. > From that same block height the interpretation of the first

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

On 26 January 2017 at 18:20, Johnson Lau via bitcoin-dev wrote: >You can’t anti-replay if you don’t even know a hardfork might happen. And I >think your hypothesis (replay reduces the incentive of split) is not supported >by the ETC/ETH split. I agree

[bitcoin-dev] Extension block softfork proposal

This is a pre-BIP which allows extra block space through a soft-fork. It is completely transparent to existing wallets (both send and receive), but new wallets taking advantage of the extra block space will have a very different user experience. I’m sure this is controversial but I think it’s

[bitcoin-dev] Changing the transaction version number to be varint

Hi all, In the transaction today we have a version field which is always 4 bytes. The rest of the integer encoding in a transaction is variable-size because it saves on bytes. Specifically, in practice this means that almost all of the transaction have bytes 2, 3 & 4 set to zero[1]. The

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> If there is a split, it becomes 2 incompatible ledgers. Not necessarily. When the BIP50 hard fork happened, it didn't create two incompatible ledgers. It *could* have, but it didn't. If every single transaction mined during that time has been "double spent" on the other chain, then it would

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

I don't think the solution should be to "fix the replay attack", but rather to "force the replay effect". The fact that transactions can be relayed should be seen as a good thing, and not something that should be fixed, or even called an "attack". The solution should be to create a "bridge" that

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

BIP50 was an accident, and my proposal is just for a planned hardfork. You can’t anti-replay if you don’t even know a hardfork might happen. And I think your hypothesis (replay reduces the incentive of split) is not supported by the ETC/ETH split. Aside the philosophical argument, your