* [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold
@ 2017-05-23 10:50 Tomas
2017-05-24 2:42 ` Erik Aronesty
0 siblings, 1 reply; 3+ messages in thread
From: Tomas @ 2017-05-23 10:50 UTC (permalink / raw)
To: Bitcoin Dev
I have a proposal that would allow each user to optionally configure the
maximum block weight at a support threshold.
It recognizes that there is no need for off chain bickering, by
providing a mechanism that lets each users freely choose their own
parameters while still maintaining full coordination of any changes.
The BIP can be found here:
https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki
It is worth noting that this proposal does neither gives more power to
miners nor reduces decentralization. Miners still rely on their blocks
being accepted by economic nodes to sell their minted coins. This
proposal doesn't change that.
Regards,
Tomas van der Wansem
bitcrust
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold
2017-05-23 10:50 [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold Tomas
@ 2017-05-24 2:42 ` Erik Aronesty
2017-05-24 8:34 ` Tomas
0 siblings, 1 reply; 3+ messages in thread
From: Erik Aronesty @ 2017-05-24 2:42 UTC (permalink / raw)
To: Tomas; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
Instead of block thresholds, use utxo bits to coordinate size changes
(larger and smaller should be allowed).
There is no reason for miners to be involved in a decision to change this
aspects of the protocol. Plenty of other ways to coordinate.
Otherwise someone can make it seem to a miner like 99pct of nodes are ready
for a larger weight.... even though that's false.
On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I have a proposal that would allow each user to optionally configure the
> maximum block weight at a support threshold.
>
> It recognizes that there is no need for off chain bickering, by
> providing a mechanism that lets each users freely choose their own
> parameters while still maintaining full coordination of any changes.
>
> The BIP can be found here:
>
> https://github.com/tomasvdw/bips/blob/master/bip-changing-
> the-maximum-block%20weight-based-on-a-support-threshold.mediawiki
>
> It is worth noting that this proposal does neither gives more power to
> miners nor reduces decentralization. Miners still rely on their blocks
> being accepted by economic nodes to sell their minted coins. This
> proposal doesn't change that.
>
> Regards,
> Tomas van der Wansem
> bitcrust
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 2297 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold
2017-05-24 2:42 ` Erik Aronesty
@ 2017-05-24 8:34 ` Tomas
0 siblings, 0 replies; 3+ messages in thread
From: Tomas @ 2017-05-24 8:34 UTC (permalink / raw)
To: erik; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
On Wed, May 24, 2017, at 04:42, Erik Aronesty wrote:
> Instead of block thresholds, use utxo bits to coordinate size changes
> (larger and smaller should be allowed).>
> There is no reason for miners to be involved in a decision to change
> this aspects of the protocol. Plenty of other ways to coordinate.
Miners cannot change the block size or any other rule without support of
the users, because their blocks and coins would be rejected. This
mechanism that Bitcoin brought us, has been working fine and I see no
reason to change it with utxo bits.
I *only* propose an optional way to synchronize changes without the
need of off chain agreements, which seems like a simple improvement over
the current situation.
>
> Otherwise someone can make it seem to a miner like 99pct of nodes are
> ready for a larger weight.... even though that's false.
I agree that the user agent signalling isn't very important, and I think
that most of us aware that you cannot rely on counting them.
>
> On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <bitcoin-
> dev@lists•linuxfoundation.org> wrote:>> I have a proposal that would allow each user to optionally
>> configure the>> maximum block weight at a support threshold.
>>
>> It recognizes that there is no need for off chain bickering, by
>> providing a mechanism that lets each users freely choose their own
>> parameters while still maintaining full coordination of any changes.>>
>> The BIP can be found here:
>>
>> https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki>>
>> It is worth noting that this proposal does neither gives more
>> power to>> miners nor reduces decentralization. Miners still rely on their
>> blocks>> being accepted by economic nodes to sell their minted coins. This
>> proposal doesn't change that.
>>
>> Regards,
>> Tomas van der Wansem
>> bitcrust
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #2: Type: text/html, Size: 3559 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-05-24 8:34 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-23 10:50 [bitcoin-dev] Proposal to allow users to configure the maximum block weight based on a support threshold Tomas
2017-05-24 2:42 ` Erik Aronesty
2017-05-24 8:34 ` Tomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox