📅 Original date posted:2015-09-18
📝 Original message:To be quite frank, I'm a little disappointed we've fallen back on arguing over numbers pulled out of a hat rather than discussing far more fundamental issues such as the dev process generally, consensus building, and our basic understanding of what Bitcoin really is, its strengths and weaknesses, where it shows most promise, and communicating a more unified vision to the industry and the public.
On September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>"But if a metric were chosen that addressed my concerns (worst case
>propagation and validation time), then I could be in favor of an
>initial
>bump that allowed a larger number of typical transactions in a block."
>
>+1. A ratio is much more valuable than a simple metric. It seems
>clearly
>difficult to identify a reasonable limit to block size, but the ratio
>between any one of several possible metrics and bytes in a block would
>work
>well and may already have a very good reasonable expected range.
>
>I like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to
>compute, then it need only be computed for all blocks less than or
>equal in
>size to the average size of the largest 200 or so blocks in the
>previous
>difficulty period. To exceed that limit, a miner would have to ensure
>that
>the block has enough BTCDD per byte. "Enough" could be hardcoded in
>each
>release, or if it's simple enough, use the ratio as computed over all
>the
>blocks in the previous difficulty period as the lower limit.
>
>notplato
>
>On Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev <
>bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Correction of a correction, in-line:
>>
>> On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> > - Many interested or at least willing to accept a "short term
>bump", a
>>> > hard fork to modify block size limit regime to be cost-based via
>>> > "net-utxo" rather than a simple static hard limit. 2-4-8 and
>17%/year
>>> > were debated and seemed "in range" with what might work as a short
>term
>>> > bump - net after applying the new cost metric.
>>>
>>> I would be careful to point out that hard numbers were deliberately
>NOT
>>> discussed. Though some general things were thrown out, they were not
>>> extensively discussed nor agreed to. I personally think 2-4 is "in
>>> range", though 8 maybe not so much. Of course it depends on exactly
>how
>>> the non-blocksize limit accounting/adjusting is done.
>>>
>>> Still, the "greatest common denominator" agreement did not seem to
>be
>>> agreeing to an increase which continues over time, but which instead
>>> limits itself to a set, smooth increase for X time and then requires
>a
>>> second hardfork if there is agreement on a need for more blocksize
>at
>>> that point.
>>>
>>
>> Perhaps it is accurate to say that there wasn't consensus at all
>except
>> that (1) we think we can work together on resolving this impasse
>(yay!),
>> and (2) it is conceivable that changing from block size to some other
>> metric might provide the basis for a compromise on near-term numbers.
>>
>> As an example, I do not think the net-UTXO metric provides any
>benefit
>> with respect to scalability, and in some ways makes the situation
>worse
>> (even though it helpfully solves an unrelated problem of spammy dust
>> outputs). But there are other possible metrics and I maintain hope
>that
>> data will show the benefit of another metric or other metrics
>combined with
>> net-UTXO in a way that will allow us to reach consensus.
>>
>> As a further example, I also am quite concerned about 2-4-8MB with
>either
>> block size or net-UTXO as the base metric. As you say, it depends on
>how
>> the non-blocksize limit accounting/adjusting is done... But if a
>metric
>> were chosen that addressed my concerns (worst case propagation and
>> validation time), then I could be in favor of an initial bump that
>allowed
>> a larger number of typical transactions in a block.
>>
>> But where I really need to disagree is on the requirement for a 2nd
>hard
>> fork. I will go on record as being definitively against this. While
>being
>> conservative with respect to exponentials, I would very much like to
>make
>> sure that there is a long-term growth curve as part of any proposal.
>I am
>> willing to accept a hard-fork if the adopted plan is too
>conservative, but
>> I do not want to be kicking the can down the road to a scheduled 2nd
>hard
>> fork that absolutely must occur. That, I feel, could be a more
>dangerous
>> outcome than an exponential that outlasts conservative historical
>trends.
>>
>> I commend Jeff for writing a Chatham-rules summary of the outcome of
>some
>> hallway conversations that occurred. On the whole I think his summary
>does
>> represent the majority view of the opinions expressed by core
>developers at
>> the workshop. I will caution though that on nearly every issue there
>were
>> those expressed disagreement but did not fight the issue, and those
>who
>> said nothing and left unpolled opinions. Nevertheless this summary is
>> informative as it feeds forwards into the design of proposals that
>will be
>> made prior to the Hong Kong workshop in December, in order that they
>have a
>> higher likelihood of success.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
>
>--
>I like to provide some work at no charge to prove my value. Do you need
>a
>techie?
>I own Litmocracy <http://www.litmocracy.com>; and Meme Racing
><http://www.memeracing.net>; (in alpha).
>I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>;
>which
>now accepts Bitcoin.
>I also code for The Dollar Vigilante <http://dollarvigilante.com/>;.
>"He ought to find it more profitable to play by the rules" - Satoshi
>Nakamoto
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/e1bb9ba2/attachment-0001.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:40:27
in reply to nevent1q…4hjj
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:40:27Event JSON
{
"id": "5ade6148e59d0bb86d975af664368ca5d2d4936de619b98bf313b390a101adca",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159627,
"kind": 1,
"tags": [
[
"e",
"4dc88d58511033587919733d4dc9dc5f297805e31bd935cb9f1c91f45ed8346b",
"",
"root"
],
[
"e",
"420c2aba6bebe9a60ce819f2621235b3c24c4e268d168a75b43ee05e57cb8c2a",
"",
"reply"
],
[
"p",
"a384795310cea1937dda4d01ee8f14ca734b9a7ab60c62114a5656706e15e47f"
]
],
"content": "📅 Original date posted:2015-09-18\n📝 Original message:To be quite frank, I'm a little disappointed we've fallen back on arguing over numbers pulled out of a hat rather than discussing far more fundamental issues such as the dev process generally, consensus building, and our basic understanding of what Bitcoin really is, its strengths and weaknesses, where it shows most promise, and communicating a more unified vision to the industry and the public.\n\nOn September 18, 2015 10:10:08 AM PDT, Dave Scotese via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\"But if a metric were chosen that addressed my concerns (worst case\n\u003epropagation and validation time), then I could be in favor of an\n\u003einitial\n\u003ebump that allowed a larger number of typical transactions in a block.\"\n\u003e\n\u003e+1. A ratio is much more valuable than a simple metric. It seems\n\u003eclearly\n\u003edifficult to identify a reasonable limit to block size, but the ratio\n\u003ebetween any one of several possible metrics and bytes in a block would\n\u003ework\n\u003ewell and may already have a very good reasonable expected range.\n\u003e\n\u003eI like BTCDaysDestroyed (BTCDD) best. If it might be time consuming to\n\u003ecompute, then it need only be computed for all blocks less than or\n\u003eequal in\n\u003esize to the average size of the largest 200 or so blocks in the\n\u003eprevious\n\u003edifficulty period. To exceed that limit, a miner would have to ensure\n\u003ethat\n\u003ethe block has enough BTCDD per byte. \"Enough\" could be hardcoded in\n\u003eeach\n\u003erelease, or if it's simple enough, use the ratio as computed over all\n\u003ethe\n\u003eblocks in the previous difficulty period as the lower limit.\n\u003e\n\u003enotplato\n\u003e\n\u003eOn Thu, Sep 17, 2015 at 10:55 PM, Mark Friedenbach via bitcoin-dev \u003c\n\u003ebitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Correction of a correction, in-line:\n\u003e\u003e\n\u003e\u003e On Wed, Sep 16, 2015 at 5:51 PM, Matt Corallo via bitcoin-dev \u003c\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e \u003e - Many interested or at least willing to accept a \"short term\n\u003ebump\", a\n\u003e\u003e\u003e \u003e hard fork to modify block size limit regime to be cost-based via\n\u003e\u003e\u003e \u003e \"net-utxo\" rather than a simple static hard limit. 2-4-8 and\n\u003e17%/year\n\u003e\u003e\u003e \u003e were debated and seemed \"in range\" with what might work as a short\n\u003eterm\n\u003e\u003e\u003e \u003e bump - net after applying the new cost metric.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I would be careful to point out that hard numbers were deliberately\n\u003eNOT\n\u003e\u003e\u003e discussed. Though some general things were thrown out, they were not\n\u003e\u003e\u003e extensively discussed nor agreed to. I personally think 2-4 is \"in\n\u003e\u003e\u003e range\", though 8 maybe not so much. Of course it depends on exactly\n\u003ehow\n\u003e\u003e\u003e the non-blocksize limit accounting/adjusting is done.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Still, the \"greatest common denominator\" agreement did not seem to\n\u003ebe\n\u003e\u003e\u003e agreeing to an increase which continues over time, but which instead\n\u003e\u003e\u003e limits itself to a set, smooth increase for X time and then requires\n\u003ea\n\u003e\u003e\u003e second hardfork if there is agreement on a need for more blocksize\n\u003eat\n\u003e\u003e\u003e that point.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e Perhaps it is accurate to say that there wasn't consensus at all\n\u003eexcept\n\u003e\u003e that (1) we think we can work together on resolving this impasse\n\u003e(yay!),\n\u003e\u003e and (2) it is conceivable that changing from block size to some other\n\u003e\u003e metric might provide the basis for a compromise on near-term numbers.\n\u003e\u003e\n\u003e\u003e As an example, I do not think the net-UTXO metric provides any\n\u003ebenefit\n\u003e\u003e with respect to scalability, and in some ways makes the situation\n\u003eworse\n\u003e\u003e (even though it helpfully solves an unrelated problem of spammy dust\n\u003e\u003e outputs). But there are other possible metrics and I maintain hope\n\u003ethat\n\u003e\u003e data will show the benefit of another metric or other metrics\n\u003ecombined with\n\u003e\u003e net-UTXO in a way that will allow us to reach consensus.\n\u003e\u003e\n\u003e\u003e As a further example, I also am quite concerned about 2-4-8MB with\n\u003eeither\n\u003e\u003e block size or net-UTXO as the base metric. As you say, it depends on\n\u003ehow\n\u003e\u003e the non-blocksize limit accounting/adjusting is done... But if a\n\u003emetric\n\u003e\u003e were chosen that addressed my concerns (worst case propagation and\n\u003e\u003e validation time), then I could be in favor of an initial bump that\n\u003eallowed\n\u003e\u003e a larger number of typical transactions in a block.\n\u003e\u003e\n\u003e\u003e But where I really need to disagree is on the requirement for a 2nd\n\u003ehard\n\u003e\u003e fork. I will go on record as being definitively against this. While\n\u003ebeing\n\u003e\u003e conservative with respect to exponentials, I would very much like to\n\u003emake\n\u003e\u003e sure that there is a long-term growth curve as part of any proposal.\n\u003eI am\n\u003e\u003e willing to accept a hard-fork if the adopted plan is too\n\u003econservative, but\n\u003e\u003e I do not want to be kicking the can down the road to a scheduled 2nd\n\u003ehard\n\u003e\u003e fork that absolutely must occur. That, I feel, could be a more\n\u003edangerous\n\u003e\u003e outcome than an exponential that outlasts conservative historical\n\u003etrends.\n\u003e\u003e\n\u003e\u003e I commend Jeff for writing a Chatham-rules summary of the outcome of\n\u003esome\n\u003e\u003e hallway conversations that occurred. On the whole I think his summary\n\u003edoes\n\u003e\u003e represent the majority view of the opinions expressed by core\n\u003edevelopers at\n\u003e\u003e the workshop. I will caution though that on nearly every issue there\n\u003ewere\n\u003e\u003e those expressed disagreement but did not fight the issue, and those\n\u003ewho\n\u003e\u003e said nothing and left unpolled opinions. Nevertheless this summary is\n\u003e\u003e informative as it feeds forwards into the design of proposals that\n\u003ewill be\n\u003e\u003e made prior to the Hong Kong workshop in December, in order that they\n\u003ehave a\n\u003e\u003e higher likelihood of success.\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e-- \n\u003eI like to provide some work at no charge to prove my value. Do you need\n\u003ea\n\u003etechie?\n\u003eI own Litmocracy \u003chttp://www.litmocracy.com\u003e and Meme Racing\n\u003e\u003chttp://www.memeracing.net\u003e (in alpha).\n\u003eI'm the webmaster for The Voluntaryist \u003chttp://www.voluntaryist.com\u003e\n\u003ewhich\n\u003enow accepts Bitcoin.\n\u003eI also code for The Dollar Vigilante \u003chttp://dollarvigilante.com/\u003e.\n\u003e\"He ought to find it more profitable to play by the rules\" - Satoshi\n\u003eNakamoto\n\u003e\n\u003e\n\u003e------------------------------------------------------------------------\n\u003e\n\u003e_______________________________________________\n\u003ebitcoin-dev mailing list\n\u003ebitcoin-dev at lists.linuxfoundation.org\n\u003ehttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/e1bb9ba2/attachment-0001.html\u003e",
"sig": "f16324503e88b51b719b579636966fe91cf3eb8fb634b4d340259f929790b30f9ff8a228b7f9e77368a965f99017f894e50579b4d2fd4c767f8ba2c3df906798"
}