Justus Ranvier [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-19 📝 Original message:On 12/19/2015 10:49 AM, ...
📅 Original date posted:2015-12-19
📝 Original message:On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote:
> I am not convinced that SW softfork should be the *only* short term
> scalability solution
I don't think SW is relevant at all with respect to scalability.
Fraud proofs are extremely important from a security perspective. The
network as it exists now places too much trust in miners. Creating a way
for non-full node clients to reject chains with contain invalid
transactions regardless of how much hashing power produces the invalid
chains is essential for the security of the network.
Adding a fraud proof system into blocks means that other features, like
committed UTXO sets, become less unsafe to deploy.
Solving transaction malleability is a very nice to have feature.
A scalability solution, IMHO, is "how do we buy some time to allow
continue usage growth while working on creating a situation where it
becomes safe to eliminate maximum block size as a consensus rule?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.sig>
📝 Original message:On 12/19/2015 10:49 AM, jl2012 via bitcoin-dev wrote:
> I am not convinced that SW softfork should be the *only* short term
> scalability solution
I don't think SW is relevant at all with respect to scalability.
Fraud proofs are extremely important from a security perspective. The
network as it exists now places too much trust in miners. Creating a way
for non-full node clients to reject chains with contain invalid
transactions regardless of how much hashing power produces the invalid
chains is essential for the security of the network.
Adding a fraud proof system into blocks means that other features, like
committed UTXO sets, become less unsafe to deploy.
Solving transaction malleability is a very nice to have feature.
A scalability solution, IMHO, is "how do we buy some time to allow
continue usage growth while working on creating a situation where it
becomes safe to eliminate maximum block size as a consensus rule?"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 23337 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151219/6fc064cf/attachment-0001.sig>