Luke Dashjr [ARCHIVE] on Nostr: 📅 Original date posted:2017-01-28 📝 Original message:On Friday, January 27, ...
📅 Original date posted:2017-01-28
📝 Original message:On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote:
> I don't think that the 17% yearly increase is too far off base considering
> current global trends(although I still don't particularly like the idea of
> centrally planning the limit, especially not that far into the future), but
> the 66% decrease first seems completely out of touch with reality.
Assume as a premise (despite your apparent disagreement below) that for
Bitcoin to function, a supermajority of economic activity needs to be verified
using full nodes operated by the recipient. Evidence suggests that at this
current time, at best 10% of economic activity is in fact using a full node to
verify the transaction. On this basis, it seems pretty clear that serious
action must be taken to change the status quo, and so for efforts to do so
without dropping the block size have proven ineffective.
> I'd also like to point out to Luke that Satoshi envisioned most full nodes
> running in data centers in the white paper, not every single user needs to
> run a full node to use bitcoin.
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they were
not isolated. But as a matter of fact, this vision has proven impossible, and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
> That a lot of people want to continue to move in that direction shouldn't
> be a surprise.
I think it's likely safe to say that if this were a possibility, everyone
would want to continue to move in that direction. But as the facts stand, it
simply isn't possible.
Luke
📝 Original message:On Friday, January 27, 2017 11:53:02 PM Andrew Johnson via bitcoin-dev wrote:
> I don't think that the 17% yearly increase is too far off base considering
> current global trends(although I still don't particularly like the idea of
> centrally planning the limit, especially not that far into the future), but
> the 66% decrease first seems completely out of touch with reality.
Assume as a premise (despite your apparent disagreement below) that for
Bitcoin to function, a supermajority of economic activity needs to be verified
using full nodes operated by the recipient. Evidence suggests that at this
current time, at best 10% of economic activity is in fact using a full node to
verify the transaction. On this basis, it seems pretty clear that serious
action must be taken to change the status quo, and so for efforts to do so
without dropping the block size have proven ineffective.
> I'd also like to point out to Luke that Satoshi envisioned most full nodes
> running in data centers in the white paper, not every single user needs to
> run a full node to use bitcoin.
Satoshi envisioned a system where full nodes could publish proofs of invalid
blocks that would be automatically verified by SPV nodes and used to ensure
even they maintained the equivalent of full node security so long as they were
not isolated. But as a matter of fact, this vision has proven impossible, and
there is to date no viable theory on how it might be fixed. As a result, the
only way for nodes to have full-node-security is to actually be a true full
node, and therefore the plan of only having full nodes in datacenters is
simply not realistic without transforming Bitcoin into a centralised system.
> That a lot of people want to continue to move in that direction shouldn't
> be a surprise.
I think it's likely safe to say that if this were a possibility, everyone
would want to continue to move in that direction. But as the facts stand, it
simply isn't possible.
Luke