Andrew Chow [ARCHIVE] on Nostr: 📅 Original date posted:2017-03-08 📝 Original message:Hi Erik, I have left you ...
📅 Original date posted:2017-03-08
📝 Original message:Hi Erik,
I have left you some comments below.
Some general questions:
How will you deal with excessive sighashing (i.e. massive transactions
that include a lot of signature verification)?
Presumably the sigops limit will increase proportionally?
On 3/8/2017 2:42 PM, Erik Aronesty via bitcoin-dev wrote:
> I woudl like to propose a BIP that works something like this:
>
> 1. Allow users to signal readiness by publishing an EB. This EB is an
> absolute upper bound, and cannot be overridden by miners. Current EB
> is 1MB, the status-quo. Maybe EB can be configured in a config file,
> not a UI, since it's an "advanced" feature.
What does EB stand for?
What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with
fake nodes publishing EBs?
How do users publish an EB? Do they use a transaction? Or is it
something that goes into the User Agent?
How high can the EB go? What is its maximum?
> 2. Miners can also signal readiness by publishing their own EB in a block.
>
> 3. If 95% of blocks within a one month signalling period contain an EB
> greater than the previous consensus EB, a fork date is triggered at 6
> months using the smallest 5th percentile EB published. (Other times
> can be selected, but these are fairly conservative, looking for
> feedback here). Miner signalling is ignored during the waiting period.
>
> 4. Block heights used for timing
>
> 5. After 6 months, any users which already have the new EB or greater
> begin actually using it to validate transactions. Users use the EB or
> the latest 95% consensus triggered value - whichever is less. This
> means that the portion of users that originally signaled for the
> increase do not have to upgrade their software to participate in the
> hard fork.
So anyone who does not change their EB are forked off of the network? If
the EB is an "advanced feature", then most users are going to be leaving
it at the default shipped with the software. That means that they will
then be forked off of the network when they don't change the EB because
it is an "advanced feature" that is more difficult to access.
>
> 6. Core can (optionally) ship a version with a default EB in-line with
> their own perceived consensus.
>
> 7. Some sort of versioning system is used to ensure that the two
> networks (old and new) are incompatible... blocks hashed in one cannot
> be used in the other.
I think this would require a soft fork beforehand in order to implement
such a system.
>
> Any users which don't already have the new EB or greater should update
> their EB within the 6 month period - or they will be excluded from the
> majority fork.
>
> It would be in the best interests of major exchanges and users would
> to publicly announce their EB's.
Why?
>
> Users are free to safely set very high EB levels, based on their
> current hardware and network speeds. These EB levels don't cause those
> users to accept invalid blocks ever. They are safe because block size
> transitions behave like normal hard forks with high miner consensus (95%).
>
> No code changes will be needed to fork the network as many times as
> both users and miners feel the need to do so. (Bitcoin core is off
> the hook for "scaling" issues...forever!)
"Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.
>
> If a smaller block size is needed, a reduced size can also be
> published and agreed upon by *both* users and miners using a the same
> mechanism, but the largest 5th percentile is used. In other words...
> the requires broad consensus to deviate from status quo and fork.
>
> Any new node can simply follow these rules to validate all the blocks
> in a chain... even if the sizes changes a lot (at most twice per year).
What if the EB of a new node is set to be smaller than the current block
size?
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/024c0a8e/attachment-0001.html>;
📝 Original message:Hi Erik,
I have left you some comments below.
Some general questions:
How will you deal with excessive sighashing (i.e. massive transactions
that include a lot of signature verification)?
Presumably the sigops limit will increase proportionally?
On 3/8/2017 2:42 PM, Erik Aronesty via bitcoin-dev wrote:
> I woudl like to propose a BIP that works something like this:
>
> 1. Allow users to signal readiness by publishing an EB. This EB is an
> absolute upper bound, and cannot be overridden by miners. Current EB
> is 1MB, the status-quo. Maybe EB can be configured in a config file,
> not a UI, since it's an "advanced" feature.
What does EB stand for?
What is the point of users publishing an EB? Is it for miners to
determine what to set theirs to? If so, what about sybil attacks with
fake nodes publishing EBs?
How do users publish an EB? Do they use a transaction? Or is it
something that goes into the User Agent?
How high can the EB go? What is its maximum?
> 2. Miners can also signal readiness by publishing their own EB in a block.
>
> 3. If 95% of blocks within a one month signalling period contain an EB
> greater than the previous consensus EB, a fork date is triggered at 6
> months using the smallest 5th percentile EB published. (Other times
> can be selected, but these are fairly conservative, looking for
> feedback here). Miner signalling is ignored during the waiting period.
>
> 4. Block heights used for timing
>
> 5. After 6 months, any users which already have the new EB or greater
> begin actually using it to validate transactions. Users use the EB or
> the latest 95% consensus triggered value - whichever is less. This
> means that the portion of users that originally signaled for the
> increase do not have to upgrade their software to participate in the
> hard fork.
So anyone who does not change their EB are forked off of the network? If
the EB is an "advanced feature", then most users are going to be leaving
it at the default shipped with the software. That means that they will
then be forked off of the network when they don't change the EB because
it is an "advanced feature" that is more difficult to access.
>
> 6. Core can (optionally) ship a version with a default EB in-line with
> their own perceived consensus.
>
> 7. Some sort of versioning system is used to ensure that the two
> networks (old and new) are incompatible... blocks hashed in one cannot
> be used in the other.
I think this would require a soft fork beforehand in order to implement
such a system.
>
> Any users which don't already have the new EB or greater should update
> their EB within the 6 month period - or they will be excluded from the
> majority fork.
>
> It would be in the best interests of major exchanges and users would
> to publicly announce their EB's.
Why?
>
> Users are free to safely set very high EB levels, based on their
> current hardware and network speeds. These EB levels don't cause those
> users to accept invalid blocks ever. They are safe because block size
> transitions behave like normal hard forks with high miner consensus (95%).
>
> No code changes will be needed to fork the network as many times as
> both users and miners feel the need to do so. (Bitcoin core is off
> the hook for "scaling" issues...forever!)
"Scaling" includes a lot more than just the block size. There is much
more to scaling than just increasing the block size.
>
> If a smaller block size is needed, a reduced size can also be
> published and agreed upon by *both* users and miners using a the same
> mechanism, but the largest 5th percentile is used. In other words...
> the requires broad consensus to deviate from status quo and fork.
>
> Any new node can simply follow these rules to validate all the blocks
> in a chain... even if the sizes changes a lot (at most twice per year).
What if the EB of a new node is set to be smaller than the current block
size?
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170308/024c0a8e/attachment-0001.html>;