📅 Original date posted:2015-09-08
📝 Original message:I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political. BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap. It also seems silly to worry
about a selfish mining attack if you're going to institute a miner vote
that an entity with that much hashrate can noticeably influence anyway.
101 is better but is still attempting to make a guess as to technological
progression quite far into the future. And then when we do finally hit 8GB
we will need yet another hard fork if we need to go bigger(or we may need
to do it earlier if the increase schedule isn't aggressive enough). And
who knows how large the ecosystem may be at that time, a hard fork may be
an undertaking of truly epic proportions due to the sheer number of devices
and embedded firmware that operates on the block chain.
I've done no math on this(posting from mobile) but something similar to
this would be reasonable, I think. Unbounded growth, as Adam points out,
is also undesirable.
Every 4032 blocks (~4 weeks), the maximum block size will be decreased by
10% *IF* a minimum of 2500 blocks has a size <= 40% of the maximum block
size at that time.
This requires a larger threshold to be crossed to move downwards, that way
we hopefully aren't oscillating back and forth constantly. I'll try to do
some blockchain research sometime this week and either back my plucked from
the air numbers or change them.
Andrew Johnson
On Sep 8, 2015 10:11 AM, "Washington Sanchez via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 1) It's not really clear to me how that would work, but assuming it does
> then it will go into a basket of attacks that are possible but unlikely due
> to the economic disincentives to do so.
>
> 2) That said, is the Achilles heal of this proposal the lack of a
> mechanism to lower the block size?
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>
> On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam at cypherspace.org> wrote:
>
>> > A selfish mining attack would have to be performed for at least 2000
>> blocks over a period of 4 weeks in order to achieve a meager 10% increase
>> in the block size.
>>
>> You seem to be analysing a different attack - I mean that if someone
>> has enough hashrate to do a selfish mining attack, then setting up a
>> system that has no means to reduce block-size risks that at a point
>> where there is excess block-size they can use that free transaction
>> space to amplify selfish mining instead of collecting transaction
>> fees.
>>
>> Adam
>>
>
>
>
> --
> -------------------------------------------
> *Dr Washington Y. Sanchez <http://onename.com/drwasho>;*
> Co-founder, OB1 <http://ob1.io>;
> Core developer of OpenBazaar <https://openbazaar.org>;
> @drwasho <https://twitter.com/drwasho>;
>
>
> _______________________________________________
> 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/20150908/e4e2989e/attachment-0001.html>;
Andrew Johnson [ARCHIVE] /
npub1lf…zuul6
2023-06-07 17:39:50
in reply to nevent1q…28cx
Author Public Key
npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6Published at
2023-06-07 17:39:50Event JSON
{
"id": "5e4fc08b2e533072e428746df59eb58f3c6ae1ee05480c0d16663f434c766890",
"pubkey": "fa69268781de33f116b423cab175d976820851d6b074d0873c920c6983eb4713",
"created_at": 1686159590,
"kind": 1,
"tags": [
[
"e",
"5db98b1bb8a695c5ded066d359dd1edd37b2315bd6a400566e7871f0b2f043bb",
"",
"root"
],
[
"e",
"908174b10449dea94ea58b9300d013acd41cb4131df6d0cc30ac9393c6588b46",
"",
"reply"
],
[
"p",
"44f6b1bc34db0cd6a353de4e8d2dcdd62b94272c5645619539442dd563a160d3"
]
],
"content": "📅 Original date posted:2015-09-08\n📝 Original message:I rather like this idea, I like that we're taking block scaling back to a\ntechnical method rather than political. BIP100 is frightening to me as it\ngives a disproportionate amount of power to the miners, who can already\ncontrol their own blocksize with a soft cap. It also seems silly to worry\nabout a selfish mining attack if you're going to institute a miner vote\nthat an entity with that much hashrate can noticeably influence anyway.\n\n101 is better but is still attempting to make a guess as to technological\nprogression quite far into the future. And then when we do finally hit 8GB\nwe will need yet another hard fork if we need to go bigger(or we may need\nto do it earlier if the increase schedule isn't aggressive enough). And\nwho knows how large the ecosystem may be at that time, a hard fork may be\nan undertaking of truly epic proportions due to the sheer number of devices\nand embedded firmware that operates on the block chain.\n\nI've done no math on this(posting from mobile) but something similar to\nthis would be reasonable, I think. Unbounded growth, as Adam points out,\nis also undesirable.\n\nEvery 4032 blocks (~4 weeks), the maximum block size will be decreased by\n10% *IF* a minimum of 2500 blocks has a size \u003c= 40% of the maximum block\nsize at that time.\n\nThis requires a larger threshold to be crossed to move downwards, that way\nwe hopefully aren't oscillating back and forth constantly. I'll try to do\nsome blockchain research sometime this week and either back my plucked from\nthe air numbers or change them.\n\nAndrew Johnson\nOn Sep 8, 2015 10:11 AM, \"Washington Sanchez via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e 1) It's not really clear to me how that would work, but assuming it does\n\u003e then it will go into a basket of attacks that are possible but unlikely due\n\u003e to the economic disincentives to do so.\n\u003e\n\u003e 2) That said, is the Achilles heal of this proposal the lack of a\n\u003e mechanism to lower the block size?\n\u003e\n\u003e 3) Let me put it another way, I've read that both Gavin and yourself are\n\u003e favorable to a dynamic limit on the block size. In your view, what is\n\u003e missing from this proposal, or what variables should be adjusted, to get\n\u003e the rules to a place where you and other Core developers would seriously\n\u003e consider it?\n\u003e\n\u003e On Wed, Sep 9, 2015 at 12:18 AM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\u003e\n\u003e\u003e \u003e A selfish mining attack would have to be performed for at least 2000\n\u003e\u003e blocks over a period of 4 weeks in order to achieve a meager 10% increase\n\u003e\u003e in the block size.\n\u003e\u003e\n\u003e\u003e You seem to be analysing a different attack - I mean that if someone\n\u003e\u003e has enough hashrate to do a selfish mining attack, then setting up a\n\u003e\u003e system that has no means to reduce block-size risks that at a point\n\u003e\u003e where there is excess block-size they can use that free transaction\n\u003e\u003e space to amplify selfish mining instead of collecting transaction\n\u003e\u003e fees.\n\u003e\u003e\n\u003e\u003e Adam\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e -------------------------------------------\n\u003e *Dr Washington Y. Sanchez \u003chttp://onename.com/drwasho\u003e*\n\u003e Co-founder, OB1 \u003chttp://ob1.io\u003e\n\u003e Core developer of OpenBazaar \u003chttps://openbazaar.org\u003e\n\u003e @drwasho \u003chttps://twitter.com/drwasho\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/20150908/e4e2989e/attachment-0001.html\u003e",
"sig": "aec4de68d336b24b25ac9124bdc4d1e7bccdab78daf25cc3c71c541883cda320d7dffa91e3c1f152d82856ae37606000e82325a2ad4ce5f2cc2dac0ca757f4a3"
}