đź“… Original date posted:2015-05-29
📝 Original message:Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution.
Regarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners.
Someone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well.
From: Tier Nolan
Sent: Friday, May 29, 2015 7:22 AM
Cc: Bitcoin Dev
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction
On Fri, May 29, 2015 at 3:09 PM, Tier Nolan <tier.nolan at gmail.com> wrote:
On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
But if there is still no consensus among developers but the "bigger blocks now" movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens.
How do you define that the movement is successful?
Sorry again, I keep auto-sending from gmail when trying to delete.
In theory, using the "nuclear option", the block size can be increased via soft fork.
Version 4 blocks would contain the hash of the a valid extended block in the coinbase.
<block height> <32 byte extended hash>
To send coins to the auxiliary block, you send them to some template.
OP_P2SH_EXTENDED <scriptPubKey hash> OP_TRUE
This transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block.
To unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig.
The transaction output can be spent in the extended block using P2SH against the scriptPubKey hash.
This means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain.
The extended chain could use the updated script language too.
This is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish.
--------------------------------------------------------------------------------
------------------------------------------------------------------------------
--------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/9eaf701c/attachment.html>;
Raystonn . [ARCHIVE] /
npub18e…20rmx
2023-06-07 15:34:13
in reply to nevent1q…f5et
Author Public Key
npub18e464uqlzh9e8qm5dmnurg39za2s9t9uxg608eppvzkhr5q3uzfqg20rmxPublished at
2023-06-07 15:34:13Event JSON
{
"id": "82e044c4342b577c4f9729083e4b7fb1d09e74ab99c2c4b8a1af05016be3b31b",
"pubkey": "3e6baaf01f15cb9383746ee7c1a225175502acbc3234f3e42160ad71d011e092",
"created_at": 1686152053,
"kind": 1,
"tags": [
[
"e",
"694beae5cf0503117bf68655e21320fb2b7f537c70de07a705defd4a792c1c4c",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-05-29\n📝 Original message:Regarding Tier’s proposal: The lower security you mention for extended blocks would delay, possibly forever, the larger blocks maximum block size that we want for the entire network. That doesn’t sound like an optimal solution.\n\nRegarding consensus for larger maximum block size, what we are seeing on this list is typical of what we see in the U.S. Congress. Support for changes by the stakeholders (support for bills by the citizens as a whole) has become irrelevant to the probability of these changes being adopted. Lobbyists have all the sway in getting their policies enacted. In our case, I would bet on some lobbying of core developers by wealthy miners.\n\nSomeone recently proposed that secret ballots could help eliminate the power of lobbyists in Congress. Nobody invests in that which cannot be confirmed. Secret ballots mean the vote you are buying cannot be confirmed. Perhaps this will work for Bitcoin Core as well.\n\n\nFrom: Tier Nolan \nSent: Friday, May 29, 2015 7:22 AM\nCc: Bitcoin Dev \nSubject: Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction\n\nOn Fri, May 29, 2015 at 3:09 PM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\n\n\n On Fri, May 29, 2015 at 1:39 PM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\n But if there is still no consensus among developers but the \"bigger blocks now\" movement is successful, I'll ask for help getting big miners to do the same, and use the soft-fork block version voting mechanism to (hopefully) get a majority and then a super-majority willing to produce bigger blocks. The purpose of that process is to prove to any doubters that they'd better start supporting bigger blocks or they'll be left behind, and to give them a chance to upgrade before that happens.\n\n How do you define that the movement is successful?\n\n\nSorry again, I keep auto-sending from gmail when trying to delete.\n\n\nIn theory, using the \"nuclear option\", the block size can be increased via soft fork.\n\n\nVersion 4 blocks would contain the hash of the a valid extended block in the coinbase.\n\n\n\u003cblock height\u003e \u003c32 byte extended hash\u003e\n\n\nTo send coins to the auxiliary block, you send them to some template.\n\n\nOP_P2SH_EXTENDED \u003cscriptPubKey hash\u003e OP_TRUE\n\n\nThis transaction can be spent by anyone (under the current rules). The soft fork would lock the transaction output unless it transferred money from the extended block.\n\n\nTo unlock the transaction output, you need to include the txid of transaction(s) in the extended block and signature(s) in the scriptSig.\n\n\nThe transaction output can be spent in the extended block using P2SH against the scriptPubKey hash.\n\n\nThis means that people can choose to move their money to the extended block. It might have lower security than leaving it in the root chain.\n\n\nThe extended chain could use the updated script language too.\n\n\nThis is obviously more complex than just increasing the size though, but it could be a fallback option if no consensus is reached. It has the advantage of giving people a choice. They can move their money to the extended chain or not, as they wish.\n\n\n\n--------------------------------------------------------------------------------\n------------------------------------------------------------------------------\n\n\n\n--------------------------------------------------------------------------------\n_______________________________________________\nBitcoin-development mailing list\nBitcoin-development at lists.sourceforge.net\nhttps://lists.sourceforge.net/lists/listinfo/bitcoin-development\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/9eaf701c/attachment.html\u003e",
"sig": "4ae14e379152d7807b7709c8514e6facb2c9aec6f76122199abf59dbbef95d5071d382e3db676f37e8f2f3a819b40513aaa882bb7ac6d2400d761aca745c18d7"
}