📅 Original date posted:2015-09-03
📝 Original message:I would be helpful to describe what is meant by "votes". As far as I
understand this would be a semi-automatic process - nodes encode values
which in turn are hardcoded in software, or is this completely automated
without any intervention at all? Is there the possibility that nodes decide
by encode votes, but somehow this decision is not adhered to? Is 4. a 51%
rule?
Under 2. it might make sense to specify values in the range (1MB steps
e.g.). The number of options could have an effect. For example if the vote
has 4 possible values or 32 possible values can make a difference in
outcomes.
With regards to 1. Bitcoin does not have a fee market, although I agree
that might be a good goal. There is no price-determination of fees and no
definition of quality of service. A fee market would entail some matching
of demand and supply to establish a price. Users would adjust fee to win a
transaction slow in a deterministic way. However currently the user has no
way of knowing what effect a fee might have. So this would necessarily
include some kind pricing-mechanism with actual commitments. Bitcoin as a
system is quite far away from such a capability. It would mean Bitcoin is
capable of adapting to how it is used. For example that would allow to
shift transactions from high demand period to low demand period. I'm not
aware of any proposal to make an actual functioning fee market in Bitcoin
(or even the conceptual primitives).
On Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Oh, and answering your question about the 1M: It is a safety rail. It
> can perform no worse on the low end than the current system. Eliminates
> unlikely scenarios that squeeze users.
>
>
> On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev
>> wrote:
>> > The repo: https://github.com/jgarzik/bip100
>>
>> What is the purpose of the newly added 1 MB floor? It seems clear from the
>> current information available that 1 MB is presently too high for the
>> limit,
>> and it is entirely one-sided to only allow increases when decreases are
>> much
>> more likely to be needed in the short term.
>>
>> Must the new size limit votes use 11 bytes of coinbase? Why not just use a
>> numeric value pushed after height? Since this is a hardfork, I suggest
>> increasing the coinbase length to allow for 100 bytes *in addition* to the
>> pushed height and size-vote.
>>
>> I suggest combining 2 & 4 into a single rule lifting the 1 MB limit to 32
>> MB
>> (or whatever value is deemed appropriate) to make it clear that the limit
>> remains a part of the consensus protocol and p2p protocol limits are not
>> to
>> have an effect on consensus rules.
>>
>> Furthermore, I suggest modifying the voting to require 50% to set the
>> limit
>> floor. This has the effect of merely coordinating what miners can already
>> effectively do today by rejecting blocks larger than some collusion-
>> determined limit.
>>
>> Thoughts?
>>
>> Luke
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/218cbfe4/attachment.html>;
Benjamin [ARCHIVE] /
npub17k…sr5tq
2023-06-07 17:39:15
in reply to nevent1q…7yfc
Author Public Key
npub17kz55p7ysz4ftvq2xyr2zamc776cygwcm5fdz8ndj3jm5umm65xq4sr5tqPublished at
2023-06-07 17:39:15Event JSON
{
"id": "0ae597e9881852cfa2a7afcb97833079494abec66d462beed95441231a05415f",
"pubkey": "f5854a07c480aa95b00a3106a17778f7b58221d8dd12d11e6d9465ba737bd50c",
"created_at": 1686159555,
"kind": 1,
"tags": [
[
"e",
"dd2b88bd76717ea27b192ada88f39a04553ef7af9be5612abef2b24bdb0dc479",
"",
"root"
],
[
"e",
"7c078242f0f7a747cde07cb603a98f5c91f8cfb2a513dc3502f7f52d59dad6f2",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-09-03\n📝 Original message:I would be helpful to describe what is meant by \"votes\". As far as I\nunderstand this would be a semi-automatic process - nodes encode values\nwhich in turn are hardcoded in software, or is this completely automated\nwithout any intervention at all? Is there the possibility that nodes decide\nby encode votes, but somehow this decision is not adhered to? Is 4. a 51%\nrule?\n\nUnder 2. it might make sense to specify values in the range (1MB steps\ne.g.). The number of options could have an effect. For example if the vote\nhas 4 possible values or 32 possible values can make a difference in\noutcomes.\n\nWith regards to 1. Bitcoin does not have a fee market, although I agree\nthat might be a good goal. There is no price-determination of fees and no\ndefinition of quality of service. A fee market would entail some matching\nof demand and supply to establish a price. Users would adjust fee to win a\ntransaction slow in a deterministic way. However currently the user has no\nway of knowing what effect a fee might have. So this would necessarily\ninclude some kind pricing-mechanism with actual commitments. Bitcoin as a\nsystem is quite far away from such a capability. It would mean Bitcoin is\ncapable of adapting to how it is used. For example that would allow to\nshift transactions from high demand period to low demand period. I'm not\naware of any proposal to make an actual functioning fee market in Bitcoin\n(or even the conceptual primitives).\n\n\n\nOn Thu, Sep 3, 2015 at 5:09 AM, Jeff Garzik via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Oh, and answering your question about the 1M: It is a safety rail. It\n\u003e can perform no worse on the low end than the current system. Eliminates\n\u003e unlikely scenarios that squeeze users.\n\u003e\n\u003e\n\u003e On Wed, Sep 2, 2015 at 8:17 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e\n\u003e\u003e On Wednesday, September 02, 2015 11:58:54 PM Jeff Garzik via bitcoin-dev\n\u003e\u003e wrote:\n\u003e\u003e \u003e The repo: https://github.com/jgarzik/bip100\n\u003e\u003e\n\u003e\u003e What is the purpose of the newly added 1 MB floor? It seems clear from the\n\u003e\u003e current information available that 1 MB is presently too high for the\n\u003e\u003e limit,\n\u003e\u003e and it is entirely one-sided to only allow increases when decreases are\n\u003e\u003e much\n\u003e\u003e more likely to be needed in the short term.\n\u003e\u003e\n\u003e\u003e Must the new size limit votes use 11 bytes of coinbase? Why not just use a\n\u003e\u003e numeric value pushed after height? Since this is a hardfork, I suggest\n\u003e\u003e increasing the coinbase length to allow for 100 bytes *in addition* to the\n\u003e\u003e pushed height and size-vote.\n\u003e\u003e\n\u003e\u003e I suggest combining 2 \u0026 4 into a single rule lifting the 1 MB limit to 32\n\u003e\u003e MB\n\u003e\u003e (or whatever value is deemed appropriate) to make it clear that the limit\n\u003e\u003e remains a part of the consensus protocol and p2p protocol limits are not\n\u003e\u003e to\n\u003e\u003e have an effect on consensus rules.\n\u003e\u003e\n\u003e\u003e Furthermore, I suggest modifying the voting to require 50% to set the\n\u003e\u003e limit\n\u003e\u003e floor. This has the effect of merely coordinating what miners can already\n\u003e\u003e effectively do today by rejecting blocks larger than some collusion-\n\u003e\u003e determined limit.\n\u003e\u003e\n\u003e\u003e Thoughts?\n\u003e\u003e\n\u003e\u003e Luke\n\u003e\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/218cbfe4/attachment.html\u003e",
"sig": "b2dbf492dc0e0648687841cb67bc24f74759824fa6f16e639ee0078102f742090a8bfe6198791d87bf7b886462f30316b8f7d515907c08f1870706f199091e9b"
}