📅 Original date posted:2023-02-04
🗒️ Summary of this message: A proposed change to switch 80 to another number in Bitcoin's codebase is discussed, with the process of issuing a PR and addressing concerns outlined.
📝 Original message:On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte <aymeric at peersm.com> wrote:
> Thanks Christopher, then I understand the process:
>
> - I must issue a PR where I switch 80 to another number, even if I am not
> a C/C++ expert it looks easy
>
Yes, this would be an easy PR, at least to start. I suspect that
longer-term, you'd need to draft some assistance to make it turn on/off
from when the bitcoin daemon is initialized. But that could wait until the
conversation has progressed some.
The harder part will be writing the initial comment, where you should
carefully explain the rationale, link to some existing conversations, try
to point out in advance the obvious objections and rationale despite them,
and explain your particular choice of number — 520 because that is a
similar limit in taproot? Some multiple of hash+signature+metadata to
satisfy others (that still might not be satisfied by any choice).
> - I must stay calm and answer all outstanding concerns about this trivial
> change
>
> - Since I am not as clever as the bitcoin devs I must be ready to revise
> my PR at any time
>
> - This could lead for the change to be from 80B to 82.xB where x comes
> from a non understandable crypto formula
>
> - I must evangelize the change worldwide
>
> - Once accepted, I must collude (pay) with the nodes/miners so they update
> at a subtile block height decided by the community
>
That is true for forks, but I don't think this is a fork. It might require
resolving some mempool issues (for instance for mining pools). But for it
to become non-optional, you'll need to demonstrate that miners and full
nodes have turned it on. Thus that is more a conversation than "collusion
(pay)".
> And then I must pray that the PR does not survive myself
>
> Looks like a pretty straight forward process.
>
I've seen worse. I co-authored TLS 1.0 (6 years) and DID 1.0 (5 years).
> I am on this list since quite some time, so, seriously, this change is
> needed, or, as I said before, deviant behaviours will happen, because the
> "witness trick" or others do not work at all, and are clearly similar to
> ethereum messy stuff
>
You have at least Concept ACK from me! ;-)
-- Christopher Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/00878238/attachment.html>;
Christopher Allen [ARCHIVE] /
npub19g…ct5d0
2023-06-07 23:19:00
in reply to nevent1q…aydw
Author Public Key
npub19g47w5ewcqlpd7n07wpkp5cvcu2gjwrse0vl47l0avwl9hu933xsqct5d0Published at
2023-06-07 23:19:00Event JSON
{
"id": "5b18a90f9e9ca80b90b8789b9a142adb2411c59a4636c61cb9e5010f0a38a958",
"pubkey": "2a2be7532ec03e16fa6ff38360d30cc714893870cbd9fafbefeb1df2df858c4d",
"created_at": 1686179940,
"kind": 1,
"tags": [
[
"e",
"db7e30240de322a59459e6f6d735c7f019f73c8194514d70467812fbd7606451",
"",
"root"
],
[
"e",
"5da0039dcc0854e6ba41fc3c5968349b44680bed942f1bab5df6959ce2fd1d9c",
"",
"reply"
],
[
"p",
"a2711d6616d348a3542bb2a791a9e51fcbc7b7d1d20652e5abe16d3e179321df"
]
],
"content": "📅 Original date posted:2023-02-04\n🗒️ Summary of this message: A proposed change to switch 80 to another number in Bitcoin's codebase is discussed, with the process of issuing a PR and addressing concerns outlined.\n📝 Original message:On Sat, Feb 4, 2023 at 12:55 PM Aymeric Vitte \u003caymeric at peersm.com\u003e wrote:\n\n\u003e Thanks Christopher, then I understand the process:\n\u003e\n\u003e - I must issue a PR where I switch 80 to another number, even if I am not\n\u003e a C/C++ expert it looks easy\n\u003e\nYes, this would be an easy PR, at least to start. I suspect that\nlonger-term, you'd need to draft some assistance to make it turn on/off\nfrom when the bitcoin daemon is initialized. But that could wait until the\nconversation has progressed some.\n\nThe harder part will be writing the initial comment, where you should\ncarefully explain the rationale, link to some existing conversations, try\nto point out in advance the obvious objections and rationale despite them,\nand explain your particular choice of number — 520 because that is a\nsimilar limit in taproot? Some multiple of hash+signature+metadata to\nsatisfy others (that still might not be satisfied by any choice).\n\n\u003e - I must stay calm and answer all outstanding concerns about this trivial\n\u003e change\n\u003e\n\u003e - Since I am not as clever as the bitcoin devs I must be ready to revise\n\u003e my PR at any time\n\u003e\n\u003e - This could lead for the change to be from 80B to 82.xB where x comes\n\u003e from a non understandable crypto formula\n\u003e\n\u003e - I must evangelize the change worldwide\n\u003e\n\u003e - Once accepted, I must collude (pay) with the nodes/miners so they update\n\u003e at a subtile block height decided by the community\n\u003e\nThat is true for forks, but I don't think this is a fork. It might require\nresolving some mempool issues (for instance for mining pools). But for it\nto become non-optional, you'll need to demonstrate that miners and full\nnodes have turned it on. Thus that is more a conversation than \"collusion\n(pay)\".\n\n\u003e And then I must pray that the PR does not survive myself\n\u003e\n\u003e Looks like a pretty straight forward process.\n\u003e\nI've seen worse. I co-authored TLS 1.0 (6 years) and DID 1.0 (5 years).\n\n\u003e I am on this list since quite some time, so, seriously, this change is\n\u003e needed, or, as I said before, deviant behaviours will happen, because the\n\u003e \"witness trick\" or others do not work at all, and are clearly similar to\n\u003e ethereum messy stuff\n\u003e\nYou have at least Concept ACK from me! ;-)\n\n-- Christopher Allen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/00878238/attachment.html\u003e",
"sig": "6daccf21572180e0f8f9a51efe4130f8e7019c90b9b98d79a57250045bb7158eb2984d7b60687d171aa84bb85a384a5c82d7e7a1914dd02bbeda5295608129c1"
}