Re: [bitcoin-dev] Properties of an ideal PoW algorithm & implementation

Repeatedly hashing to make it so that lossy implementations just fail sounds like a great idea. Also relying on a single crypto primitive which is as simple as possible is also a great idea, and specifically using blake2b is conservative because not only is it simple but its block size is larger

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

On Tue, Apr 18, 2017 at 3:43 AM, Jonas Schnelli wrote: > > Hi Dave > > *1. I agree that we need to have a way for pruned nodes to partially serve > historical blocks.* > My personal measurements told me that around ~80% of historical block > serving are between tip and

Re: [bitcoin-dev] Properties of an ideal PoW algorithm & implementation

Natanael, === Metal Layers === One factor in chip cost other than transistor count is the number of layers required to route all the interconnects in the desired die area constraint. The need for fewer layers can result in less patent-able costs of layering technology. Fewer layers are

Re: [bitcoin-dev] I do not support the BIP 148 UASF

The "UASF movement" seems a bit premature to me - I doubt UASF will be necessary if a WTXID commitment is tried first. I think that should be first-efforts focus. On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Apr 15,

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

>Financially incentivising nodes is a really weird area because it would allow someone to essentially automate the deployment of nodes. i.e. if a node can pay for itself 100% (even at a lesser value, it just becomes cheaper overall), you could write an application that uses an AWS API or a digital

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

I'd like to add to this. There is definitely a barrier of entry with regards to setting up a full node. Unless you're living in a first world country, the bandwidth requirements alone, will outright prevent you from even setting up a full node (sync since genesis). To maintain that also

Re: [bitcoin-dev] Properties of an ideal PoW algorithm & implementation

On Tue, 2017-04-18 at 12:34 +0200, Natanael via bitcoin-dev wrote: > To prove that an implementation is near optimal, you would show > there's a minimum number of necessary transistor activations per > computed hash, and that your implementation is within a reasonable > range of that number.  I'm