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

2017-04-18 Thread Jonas Schnelli via bitcoin-dev
Hi Dave > A node that stores the full blockchain (I will use the term archival node) > requires over 100GB of disk space, which I believe is one of the most > significant barriers to more people running full nodes. And I believe the > ecosystem would benefit substantially if more users were run

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

2017-04-18 Thread Natanael via bitcoin-dev
To expand on this below; Den 18 apr. 2017 00:34 skrev "Natanael" : IMHO the best option if we change PoW is an algorithm that's moderately processing heavy (we still need reasonably fast verification) and which resists partial state reuse (not fast or fully "linear" in processing like SHA256) jus

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

2017-04-18 Thread Tom Zander via bitcoin-dev
On Monday, 17 April 2017 08:54:49 CEST David Vorick via bitcoin-dev wrote: > The best alternative today to storing the full blockchain is to run a > pruned node The idea looks a little overly complex to me. I suggested something similar which is a much simpler version; https://zander.github.io/sc

Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

2017-04-18 Thread Kekcoin via bitcoin-dev
> After some thought I managed to simplify the original uaversionbits proposal > introducing a simple boolean flag to guarantee lock-in of a BIP9 deployment > by the timeout. This seems to be the simplest form combining optional flag > day activation with BIP9. This brings the best of both world

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

2017-04-18 Thread Tier Nolan via bitcoin-dev
This has been discussed before. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008101.html including a list of nice to have features by Maxwell https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008110.html You meet most of these rules, though you do have to down

Re: [bitcoin-dev] Transaction signalling

2017-04-18 Thread Marcel Jamin via bitcoin-dev
Probably a bad idea for various reasons, but tagging (fee paying) transactions with info about the capabilities of the node that created it might be interesting? Might be useful to gauge economic support for certain upgrades, especially if excluding long transaction chains, etc. In the very least i

Re: [bitcoin-dev] Transaction signalling

2017-04-18 Thread Erik Aronesty via bitcoin-dev
Just to be clear, the tagging would occur on the addresses, and the weighting would be by value, so it's a measure of economic significance. Major exchanges will regularly tag massive amounts of Bitcoins with their capabilities. Just adding a nice bit-field and a tagging standard, and then chartin

Re: [bitcoin-dev] Transaction signalling

2017-04-18 Thread Christian Decker via bitcoin-dev
I really like the idea of extending signalling capabilities to the end-users. It gives stakeholders a voice in the decisions we take in the network, and are a clear signal to all other involved parties. It reminds me of a student thesis I supervised some time ago [1], in which we explored various s

Re: [bitcoin-dev] Transaction signalling

2017-04-18 Thread Tim Ruffing via bitcoin-dev
I don't have an opinion on whether signaling is a good idea in general. However I don't think that using addresses is a good idea, because this has privacy implications. For example, it makes it much easier to link the addresses, e.g., inputs with change address. (The change address votes for the

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

2017-04-18 Thread Aymeric Vitte via bitcoin-dev
>From the initial post " The situation would likely become problematic quickly if bitcoin-core were to ship with the defaults set to a pruned node." Sorry to be straight, I read the (painful) thread below, and most of what is in there is inept, wrong, obsolete... or biased, cf the first sentence a