Sancho Panza [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-04-03 to 2017-05-21
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:01:21

- reply

📅 Original date posted:2017-05-21
📝 Original message:I'm pleased to announce the completion of a Bitcoin Core implementation of BIP135:
https://github.com/bitcoin/bitcoin/pull/10437
Review comments appreciated, and happy to discuss / answer questions about the implementation in this thread or on Github.
Sancho
BIP135: https://github.com/bitcoin/bips/blob/master/bip-0135.mediawiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170521/8ec03f0b/attachment.html>

2023-06-07 18:00:52

- reply

📅 Original date posted:2017-05-07
📝 Original message:Hola,
I've submitted the generalized versionbits specification for BIP number assignment:
https://github.com/bitcoin/bips/pull/532
Your feedback and comments welcome.
The spec has been updated to include a link to the reference implementation.
I hope to find time soon to produce a similar reference implementation on Bitcoin Core.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170507/e3a5fded/attachment.html>

2023-06-07 18:00:33

- reply

📅 Original date posted:2017-04-20
📝 Original message:Dear all,
An initial reference implementation of bip-genvbvoting (spec: [1]) is now available at
https://github.com/sanch0panza/bitcoin/commits/genvbvoting-bu-dev-clean1
starting at commit fdd83383436ee43b072c258d4a6feb713902c77e .
This development is based against the Bitcoin Unlimited 'dev' branch, and has been submitted as PR458 to BU [2].
The naming of the new 'bipgenvb_forks' output section in the 'getblockchain' RPC interface is to be considered temporary while the BIP has no formal number.
I would be happy to get any feedback while I implement a corresponding pull request for a reference implementation on Bitcoin Core. Due to other commitments this may come at a later stage - if someone else is eager to port it over, please feel free.
Regards,
Sancho
[1] https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
[2] https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/458
P.S. The revised "unknown version check" code is considered an implementation specific and not part of core functionality, and is consequently not fully covered by regression tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170420/3307cbdf/attachment.html>

2023-06-07 18:00:01

- reply

📅 Original date posted:2017-04-13
📝 Original message:Thomas,
I wonder if you've seen my proposal on how to make BIP9 more configurable:
https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
This could be extended with a coinbase signaling feature as you suggest.
This could include parameter information for forks which a miner is signaling, for coordination.
Currently I've not included something like this, but it might make a nice addition.
One problem is the limited space in coinbase for embedding data on the large number of possible independent deployments.
Regards,
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170413/99093746/attachment.html>

2023-06-07 18:00:01

- reply

📅 Original date posted:2017-04-13
📝 Original message:> However, my point is that the threshold should be [...] not fixed in the soft-fork proposal
My proposal makes it configurable (as well as window size, grace period etc.)
> I agree that coinbase space might be a limitation.
I still like the coinbase idea though - more than using up the BIP9 versionbits range for verbose signaling.
BIP9 (and other proposals which use those 29 versionbits) currently assume that the participants on the network will coordinate in some form or other, to agree on what the bits mean (in terms of change deployments).
It would be very easy to also agree on a set of "standard" threshold levels and map those onto e.g. 1 byte.
Then, in the coinbase, one could have pairs of bit numbers and bytes, e.g. "/1A/2B/3C/" where the bytes values corresponding to 'A', 'B', 'C', ... are standardized deployment schedules that people find useful.
So a BIP9 conformant schedule could be A = 95% / 2016 window,
while B = 75%/2016, etc.
This would be quite a compact yet still readable signaling. The space of values is large enough that I doubt we'd see much contention.
Regards
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170413/fd2d178a/attachment.html>

2023-06-07 17:59:58

- reply

📅 Original date posted:2017-04-11
📝 Original message:Hi,
The link below includes documentation about a proposed CSV-based file format for fork deployment data (tentative config filename: forks.csv). This is planned to be used by my reference implementation of bip-genvbvoting (which is still in development - TBA later).
Other BIP9 improvement proposals are of course encouraged to use this format, and I'm happy to discuss extensions of it for things like supporting flag days or direct-to-activation transitions.
Regards,
Sancho
https://raw.githubusercontent.com/sanch0panza/bitcoin/genvbvoting-bu-dev/doc/genvbvoting.md
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/b925eb64/attachment.html>

2023-06-07 17:59:54

- reply

📅 Original date posted:2017-04-11
📝 Original message:Tom Zander wrote:
> The version field is still needed to actually allow future block version upgrades. We would cut off our road forward if that were to be blocked.
I tend to agree, if all 32 bits were given up to grinding.
But it's worth pointing out that BIP9 is purely informational, and the top 3 bits are still reserved for other purposes. One of them could perhaps be used to signal for an extended version field somewhere else, leaving the bottom 29 as entropy?
Not a direction I prefer, but just a technical possibility perhaps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/25ea97e0/attachment-0001.html>

2023-06-07 17:59:53

- reply

📅 Original date posted:2017-04-11
📝 Original message:> I completely agree that it will be in the long term interest of bitcoin to migrate, gradually, toward a commoditized POW away from the current mass centralization. There is a big problem here though: Hundreds of millions of dollars have been spent on the current algorithm, and will be a huge loss if this is not done slowly enough, and the miners who control the chain currently would likely never allow this change to happen.
> Do you have any ideas regarding how to mitigate the damage of such a change for the invested parties? Or even how we can make the change agreeable for them?
Apologies for interjecting a thought on this topic.
My belief is that Bitcoin could grow freely, and become worth enough so that mining becomes profitable even for those of us in countries without free / subsidized electricity.
By that time, buying commodity mining equipment (ASIC-based) from major manufacturers should be no problem, esp. not for existing Bitcoin holders.
I see no sign that current major miners are principally opposed to such a natural process of decentralization of Bitcoin mining.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170411/e3decc02/attachment.html>

2023-06-07 17:59:29

- reply

📅 Original date posted:2017-04-06
📝 Original message:Hi all,
I have put up an initial draft of the full 'bip-genvbvoting' (generalized version bits voting) specification for review:
https://github.com/sanch0panza/bips/blob/bip-genvbvoting/bip-genvbvoting.mediawiki
Comments are again most welcome - and my thanks to those reviewers who took a look at the initial rough draft [1].
A prime goal is that this BIP proposal should end up allowing full backward compatibility with the existing BIP9 state machine, if wishing to do so for a deployment. In fact, this will be necessary to maintain full compatibility with any ongoing deployments.
I will work on a reference implementation which might also turn up inadequacies of the proposed specification. A link to this will follow once it is mature enough for review.
Sancho
[1]https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013969.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/cfcbb5b6/attachment.html>

2023-06-07 17:59:03

- reply

📅 Original date posted:2017-04-08
📝 Original message:Thomas,
> the change is not opt-in and will require coordination; and the continuation of the chain thereafter depends on people actually running the hard-fork code, not just being aware there is something happening.
This situation applies to soft forks as well.
- if you wish your software to validate correctly, it is not opt-in
- it requires coordination to activate without much orphan risk to miners (hence BIP9). Witness the long preparation time ahead of SegWit deployment for wallet providers, miners etc. to coordinate to support it on their systems
- after activation, it depends on people running it (most notably miners, otherwise the soft-fork is no longer enforced leading to a hard fork)
- awareness alone does not ensure full validation capability is retained during a soft fork
Therefore, these differences seem insignificant enough to merit treating soft and hard forks equal in terms of the coordination features afforded through the versionbits.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/973f66ea/attachment.html>

2023-06-07 17:59:02

- reply

📅 Original date posted:2017-04-04
📝 Original message:> BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it
> not being applicable to hardforks. BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process smoother
> this way. But the same is not true of hardforks: miners are essentially
> irrelevant to them, and cannot make the process any smoother.
I accept that BIP9 is inherently concerned only with softforks, as it is explicit about this in every instance.
However, I see no fundamental distinction between the 'royal privilege' assigned to miners w.r.t. softfork activation and the role they would play in properly coordinated hardforks.
In either case, the majority of miners would hopefully want to wait for the right conditions to create the fork block, whether that block be the first one to contain SegWit transactions or the first one to be larger than 1MB (to give two current examples).
The advance coordination with the rest of the users in the system seems important in either case.
This is a big motivator for this BIP: the versionbits can be used as a coordination mechanism for hardforks just as much as softforks.
With the added flexibility offered by this BIP, miners could use these bits to make the process smoother for softforks as well as hardforks.
For example (this is an idea I did not write in the initial BIP draft), the period for which a fork on a particular bit remains LOCKED_IN could be made customizable too, instead of one single retargeting period.
This would allow fork implementors to specify a longer adaptation period suitable to the impacts of the feature they are planning to deploy.
> Therefore, BIP 9 and any miner signalling in general is not very useful
> for deploying these.
I think BIP9 is a very useful tool that allows a decent determination of how much of the hashing power supports a particular fork proposal.
My view is that both soft and hard forks without support from the majority of miners place themselves at high risk.
In general every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it.
It seems to me that this somewhat balances out the (dis)advantages and effectively puts these fork types on a similar footing.
This is a rationale for generalizing the signaling mechanism introduced by BIP9.
In practice, developers will still need to choose whether their feature is best deployed by softfork or hardfork. This proposal affords them that choice, and does not propose any arbitrary conditions (e.g. a predefined split of the versionbits range into particular categories of forks or activation levels).
> Softforks are not required to use BIP 9, and even if they do, they are not
> required to use the recommended thresholds.
This is true, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork which was on the Core roadmap to accomodate certain wishlist items that cannot easily be addressed by softforks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170404/07c94625/attachment-0001.html>

2023-06-07 17:59:01

- reply

📅 Original date posted:2017-04-04
📝 Original message:Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is more complete.
For now I think more discussion will be very helpful.
I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes.
The entire point of BIP9 is to allow nodes that do not know about an upgrade
to still have a functional state machine. But I don’t see how you can have a
state machine if the two basic variables that drive it are not specified.
What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same.
But the parameters that decide those transitions would be unique per bit.
I think you misunderstood me if you think there will be strictly one singular state machine.
Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently.
An initial implementation might provide this all in compiled code.
A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations.
But in my opinion we would not be able to have a state machine without those
variables in the actual BIP because old nodes would miss the data to
transition to certain states.
As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this.
This proposal does not fundamentally change that situation.
Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse
the CSV one). Maybe we can come up with 3 default sets of properties and
when a proposal starts to use bit 11 it behaves differently than if it uses
22.
One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples.
I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds).
Of course in reality most bits are unused today.
Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured.
Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170404/9f226b05/attachment-0001.html>

2023-06-07 17:59:01

- reply

📅 Original date posted:2017-04-04
📝 Original message:[Apologies, reposting this in an attempt to improve on the botched formatting of previous reply. I am still getting used to the limitations of this mail service.]
Thanks for the feedback.
I'll post a link to more refined proposal on github once that elaboration is more complete.
For now I think more discussion will be very helpful.
I think the flexibility around the tallying window size will take the most careful consideration, so that a user of this proposal can retain full compatibility with BIP9 for a certain versionbit if (s)he wishes.
> The entire point of BIP9 is to allow nodes that do not know about an upgrade
> to still have a functional state machine. But I don’t see how you can have a
> state machine if the two basic variables that drive it are not specified.
What I mean by the state machine remaining essentially unchanged is that its basic design (states and transitions) would remain the same.
But the parameters that decide those transitions would be unique per bit.
I think you misunderstood me if you think there will be strictly one singular state machine.
Instead nodes would effectively be running a state machine instance for each signaling bit - with each state machine possibly (but not necessarily!) configured differently.
An initial implementation might provide this all in compiled code.
A slightly more sophisticated implementation would push the signaling configuration mostly into an external configuration file which could adhere to a fixed format and could easily be adapted and shared between implementations.
> But in my opinion we would not be able to have a state machine without those
> variables in the actual BIP because old nodes would miss the data to
> transition to certain states.
As I see it, this is the same situation we are in now with old nodes - they see that there is some action on unknown bits, but they can do nothing more than warn their operators about this.
This proposal does not fundamentally change that situation.
> Maybe an idea; we have 30 bits. 2 currently in use (although we could reuse
> the CSV one). Maybe we can come up with 3 default sets of properties and
> when a proposal starts to use bit 11 it behaves differently than if it uses
> 22.
One could place conventions on how certain bit ranges are used, but I don't much see the point of the BIP doing this, although it could suggest examples.
I would prefer if the BIP's reference implementation provides strict BIP9 compatibility in that how it configures the bits (i.e. all with 2016 block windows evaluated in strict synchronicity with BIP9, and default 95% thresholds).
Of course in reality most bits are unused today.
Someone wishing to use a bit for a feature deployment would announce so publicly (e.g. in a BIP) and release an implementation which is suitably configured.
Others wishing to provide compatibility with that feature would adjust their code and bip-genvbvoting configuration files accordingly.
Sancho
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170404/09cb963b/attachment.html>

2023-06-07 17:59:00

- reply

📅 Original date posted:2017-04-03
📝 Original message:¡Hola!
Please find below a proposal [resubmission] for a new informational BIP
provisionally named 'bip-genvbvoting'.
I present it here in rough draft for your esteemed consideration and as
a basis for discussion.
Best regards,
Sancho
--- begin draft of bip-genvbvoting ---
==Preamble==
BIP: ?
Title: Generalized version bits voting
Author: Sancho Panza <sanch0panza at protonmail.com>
Status: Draft
Type: Informational
Created: 2017-03-29
Replaces: 9
License: CC0-1.0
GNU-All-Permissive
==Abstract==
This document describes a generalized version bits voting scheme based
on and intended to replace BIP9.
The generalization consists of allowing each version bit to be treated
individually using a configurable percentage threshold and window size,
instead of the fixed 95% (mainnet) and 2016 block window specified in
BIP9.
The state machine and governing parameters (name, bit, starttime,
timeout) remain as is, but additional parameters called 'threshold' and
'windowsize' are added to the per-bit set.
As before, a set of per-chain parameters will exist for the version bits
governed by BIP9.
==Motivation==
The Bitcoin protocol requires a flexible consensus-finding scheme
to ensure that it can adapt to the needs of the market (its users) and
remain competitive as an electronic payment system.
While BIP9 has served the community reasonably well until now, the
author remarks several shortcomings in its approach:
- it limits itself to backward-compatible changes, precluding its
applicability to hard forks
- a fixed 95% threshold is not flexible enough to allow for a 'spectrum
of contentiousness' to be represented
- the 95% threshold allows small minorities to veto proposed changes,
lead to stagnation (viz. current standoffs)
A more generalized implementation of voting on changes using version bits
can address these issues in a way that can satisfy the needs of both soft
and hard forks, as well as represent varying degrees of contentiousness.
==Specification==
To be elaborated.
It is thought that only cosmetic changes are needed to generalize from
only soft forks to 'soft or hard forks', and to add the additional
per-bit parameters 'threshold' and 'windowsize'
References to fixed values will need to be eliminated and replaced
by respective parameters.
The design of the state machine is envisioned to remain unchanged.
==Implementation==
A reference implementation can be constructed after elaboration of
the specification.
==Copyright==
This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal
and GNU All-Permissive licenses.
--- end draft of bip-genvbvoting ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170403/fe041087/attachment.html>