rich1.0npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqhttps://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqnjumphttps://nostr.aeđź“… Original date posted:2015-06-13
📝 Original message:That’s exactly the problem with Bitcoin - it was supposed to be the case that users ARE the miners and node operators…but…alas…
> On Jun 13, 2015, at 3:20 PM, Danny Thorpe <danny.thorpe at gmail.com> wrote:
>
> Please forgive my ignorance, but why should Bitcoin users have a say in block size limits? It's the miners and Bitcoin node operators that bear the burden of managing large blocks, no?
>
> Users voting on network parameters sounds like neighbors voting on how deep my swimming pool should be.
>
> Thanks,
> -Danny
>
> On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd <pete at petertodd.org <mailto:pete at petertodd.org>> wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html <https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html>
>
> --
> 'peter'[:-1]@petertodd.org <http://petertodd.org/>
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> 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/20150613/0b7a0b67/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/0b7a0b67/attachment.sig>