Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2017-01-28 Thread Matt Corallo via bitcoin-dev
Replies inline. On 01/28/17 07:28, Johnson Lau wrote: > >> On 28 Jan 2017, at 10:32, Matt Corallo > > wrote: >> >> Looks cool, though I have a few comments inline. >> >> One general note - it looks like you're letting complexity run

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2017-01-27 Thread Matt Corallo via bitcoin-dev
Oops, forgot to mention, in the "parent" (ie old) block header, we should: 1) fix the version field so its a static constant 2) swap first 2 bytes of the merkle root with the timestamp's two high-order bytes (preferably more, I'm not sure how much ASIC hardware has timestamp-rolling in it

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2017-01-27 Thread Matt Corallo via bitcoin-dev
Looks cool, though I have a few comments inline. One general note - it looks like you're letting complexity run away from you a bit here. If the motivation for something is only weak, its probably not worth doing! A hard fork is something that must be undertaken cautiously because it has so much

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Tier Nolan via bitcoin-dev
On Wed, Dec 14, 2016 at 3:45 PM, Johnson Lau wrote: > I think that’s too much tech debt just for softforkability. > > The better way would be making the sum tree as an independent tree with a > separate commitment, and define a special type of softfork (e.g. a special > BIP9 bit).

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Tier Nolan via bitcoin-dev
On Wed, Dec 14, 2016 at 10:55 AM, Johnson Lau wrote: > In a sum tree, however, since the nSigOp is implied, any redefinition > requires either a hardfork or a new sum tree (and the original sum tree > becomes a placebo for old nodes. So every softfork of this type creates a > new

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Johnson Lau via bitcoin-dev
> On 14 Dec 2016, at 19:07, Luke Dashjr wrote: > > On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote: >> There is no reason to use a timestamp beyond 4 bytes. > > Actually, there is: lock times... my overflow solution doesn't have a > solution >

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Johnson Lau via bitcoin-dev
> On 5 Dec 2016, at 04:00, adiabat wrote: > > Interesting stuff! I have some comments, mostly about the header. > > The header of forcenet is mostly described in Luke’s BIP, but I have made > some amendments as I implemented it. The format is (size in parentheses; > little

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Luke Dashjr via bitcoin-dev
On Wednesday, December 14, 2016 11:01:58 AM Johnson Lau via bitcoin-dev wrote: > There is no reason to use a timestamp beyond 4 bytes. Actually, there is: lock times... my overflow solution doesn't have a solution to that. :x ___ bitcoin-dev mailing

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Johnson Lau via bitcoin-dev
There is no reason to use a timestamp beyond 4 bytes. Just let it overflow. If a blockchain is stopped for more than 2^31 seconds, it’s just dead. > On 5 Dec 2016, at 19:58, Tom Zander via bitcoin-dev > wrote: > > On Sunday, 4 December 2016 21:37:39 CET

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-14 Thread Johnson Lau via bitcoin-dev
I think the biggest problem of sum tree is the lack of flexibility to redefine the values with softforks. For example, in the future we may want to define a new CHECKSIG with witness script version 1. That would be counted as a SigOp. Without a sum tree design, that’d be easy as we could just

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-11 Thread Tier Nolan via bitcoin-dev
On Sat, Dec 10, 2016 at 9:41 PM, Luke Dashjr wrote: > On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote: > > Any new merkle algorithm should use a sum tree for partial validation and > > fraud proofs. > > PR welcome. > Fair enough. It is pretty basic.

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-10 Thread Luke Dashjr via bitcoin-dev
On Saturday, December 10, 2016 9:29:09 PM Tier Nolan via bitcoin-dev wrote: > On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Something not yet done: > > 1. The new merkle root algorithm described in the MMHF BIP > > Any new merkle

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-10 Thread Tier Nolan via bitcoin-dev
On Sun, Dec 4, 2016 at 7:34 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Something not yet done: > 1. The new merkle root algorithm described in the MMHF BIP > Any new merkle algorithm should use a sum tree for partial validation and fraud proofs. Is there

Re: [bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-10 Thread Tom Zander via bitcoin-dev
On Sunday, 4 December 2016 21:37:39 CET Hampus Sjöberg via bitcoin-dev wrote: > > Also how about making timestamp 8 bytes? 2106 is coming up soon > > AFAICT this was fixed in this commit: > https://github.com/jl2012/bitcoin/commit/ fa80b48bb4237b110ceffe11edc14c813 >

[bitcoin-dev] Forcenet: an experimental network with a new header format

2016-12-04 Thread Johnson Lau via bitcoin-dev
Based on Luke Dashjr’s code and BIP: https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki , I created an experimental network to show how a new header format may be implemented. Basically, the header hash is calculated in a way that non-upgrading nodes would see it as a block with