>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
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
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
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
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
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
> 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
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
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
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
10 matches
Mail list logo