📅 Original date posted:2015-07-31
📝 Original message:1. Data centers are not some uniform group of businesses with identical
policies nor firms with identical laws applied. The ability to get a search
warrant at a Swedish hosting provider will be dramatically different than a
Singaporean business. Similar to the decentralized nature of bitcoin, these
businesses are independent and varied - it would be difficult for
authorities to conduct a widescale attack on nodes worldwide, especially
given current laws. It would also be ineffective since any hacked/seized
host can be replaced quickly with a competitor service in a different
jurisdiction.
2. Personal residences and non-data center businesses are not immune to
theft, blackmail, seizure, hacking, etc. Depending upon the adversary and
method of attack, many users would be no worse off with their nodes not
located on premise. As alluded to above, it's a lot easier and less costly
to spin up a new 3rd party host than it is to replace a stolen laptop.
There is nothing inherently wrong with data centers/hosting providers
playing a significant (but not central) role in decentralized services.
Users who choose to use a VPS are not contributing to bitcoin in some sort
of inferior capacity. I'll posit that 3rd party providers are not an ideal
place to hold private keys, but that is off topic.
On Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think trust the data-center logic obviously fails, and I was talking
> about this scenario in the post you are replying to. You are trusting the
> data-center operator period. If one could trust data-centers to run
> verified code, to not get hacked, filter traffic, respond to court orders
> without notifying you etc that would be great but that's unfortunately not
> what happens.
>
> Data-center operators are bound to follow laws, including NSLs and gag
> orders. They also get hacked, employ humans who can be corrupt,
> blackmailed, and themselves centralisation points for policy attack.
> Snowden related disclosures and keeping aware of security show this is very
> real.
>
> This isn't much about bitcoin even, its just security reality for hosting
> anything intended to be secure via decentralisation, or just hosting in
> general while at risk of political or policy attack.
>
> Adam
> On Jul 31, 2015 10:39, "jl2012 via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> There is a summary of the proposals in my previous mail at
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html
>>
>> I think there could be a compromise between Gavin's BIP101 and Pieter's
>> proposal (called "BIP103" here). Below I'm trying to play with the
>> parameters, which reasons:
>>
>> 1. Initiation: BIP34 style voting, with support of 750 out of the last
>> 1000 blocks. The "hardfork bit" mechanism might be used:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html
>>
>> Rationale: This follows BIP101, to make sure the new chain is secure.
>> Also, no miner would like to be the first one to mine a large block if they
>> don't know how many others would accept it.
>>
>> 2. Starting date: 30 days after 75% miner support, but not before
>> 2016-01-12 00:00 UTC
>>
>> Rationale: A 30-day grace period is given to make sure everyone has
>> enough time to follow. This is a compromise between 14 day in BIP101 and 1
>> year in BIP103. I tend to agree with BIP101. Even 1 year is given, people
>> will just do it on the 364th day if they opt to procrastinate.
>>
>> 2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in
>> China. Most pool operators and devs should be back from new year holiday
>> and not sleeping. (If the initiation is delayed, we may require that it
>> must be UTC Tuesday midnight)
>>
>> 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied
>> by 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on
>> 2017-05-11.
>>
>> Rationale: Instead of jumping to 8MB, I suggest to increase it gradually
>> to 8MB in 16 months. 8MB should not be particularly painful to run even
>> with current equipment (you may see my earlier post on bitctointalk:
>> https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed
>> by Chinese miners, who control >60% of the network.
>>
>> 4. After 8MB is reached, the block size will be increased by 6.714% every
>> 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or
>> double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on
>> 2042-11-17.
>>
>> Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%
>> p.a. of BIP101. This will take us almost 8 years from now just to go back
>> to the original 32MB size (4 years for BIP101 and 22 years for BIP103)
>>
>> SSD price is expected to drop by >50%/year in the coming years. In 2020,
>> we will only need to pay 2% of current price for SSD. 98% price reduction
>> is enough for 40 years of 27.67% growth.
>> Source:
>> http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures
>>
>> Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%
>> should be safe at least for the coming 10 years.
>> Source:
>> https://www.telegeography.com/research-services/global-bandwidth-forecast-service/
>>
>> The final cap is a compromise between 8192MB at 2036 of BIP101 and
>> 2048MB at 2063 of BIP103
>>
>>
>> -----------------------------------
>>
>> Generally speaking, I think we need to have a faster growth in the
>> beginning, just to normalize the block size to a more reasonable one. After
>> all, the 1MB cap was introduced when Bitcoin was practically worthless and
>> with inefficient design. We need to decide a new "optimal" size based on
>> current adoption and technology.
>>
>> About "fee market": I do agree we need a fee market, but the fee pressure
>> must not be too high at this moment when block reward is still miner's main
>> income source. We already have a fee market: miners will avoid building big
>> blocks with low fee because that will increase the orphan risk for nothing.
>>
>> About "secondary layer": I respect everyone building secondary layer over
>> the blockchain. However, while the SWIFT settlement network is processing
>> 300tps, Bitcoin's current 7tps is just nothing more than an experiment. If
>> the underlying settlement system does not have enough capacity, any
>> secondary layer built on it will also fall apart. For example, people may
>> DoS attack a Lightening network by provoking a huge amount of settlement
>> request which some may not be confirmed on time. Ultimately, this will
>> increase the risk of running a LN service and increase the tx fee inside
>> LN. After all, the value of secondary layer primarily comes from instant
>> confirmation, not scarcity of the block space.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> 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/20150731/faab5248/attachment.html>;
Ivan Brightly [ARCHIVE] /
npub1hn…4p3n4
2023-06-07 15:44:27
in reply to nevent1q…2l6t
Author Public Key
npub1hn9vjtvdlnllrltesscgtnplu0ev2sreey03kjh3k07zmvd9zgus24p3n4Published at
2023-06-07 15:44:27Event JSON
{
"id": "55c26ae14534b15c721b94105fb098dd0ef418a921ec8e5fa55980b0919adcb3",
"pubkey": "bccac92d8dfcfff1fd79843085cc3fe3f2c54079c91f1b4af1b3fc2db1a51239",
"created_at": 1686152667,
"kind": 1,
"tags": [
[
"e",
"3d7130c3fd6ea317928489944f5ed584c66730d51fea19eef11457fbe9e27424",
"",
"root"
],
[
"e",
"0118f55899e1b4d7206baecd036c206bd38acb9536e267a81311bb8205babb13",
"",
"reply"
],
[
"p",
"5c3ef6343546506d07db7fa3f0dd3ff0b03c2f8d782fc5893a8f02abe86ab370"
]
],
"content": "📅 Original date posted:2015-07-31\n📝 Original message:1. Data centers are not some uniform group of businesses with identical\n policies nor firms with identical laws applied. The ability to get a search\n warrant at a Swedish hosting provider will be dramatically different than a\n Singaporean business. Similar to the decentralized nature of bitcoin, these\n businesses are independent and varied - it would be difficult for\n authorities to conduct a widescale attack on nodes worldwide, especially\n given current laws. It would also be ineffective since any hacked/seized\n host can be replaced quickly with a competitor service in a different\n jurisdiction.\n 2. Personal residences and non-data center businesses are not immune to\n theft, blackmail, seizure, hacking, etc. Depending upon the adversary and\n method of attack, many users would be no worse off with their nodes not\n located on premise. As alluded to above, it's a lot easier and less costly\n to spin up a new 3rd party host than it is to replace a stolen laptop.\n\nThere is nothing inherently wrong with data centers/hosting providers\nplaying a significant (but not central) role in decentralized services.\nUsers who choose to use a VPS are not contributing to bitcoin in some sort\nof inferior capacity. I'll posit that 3rd party providers are not an ideal\nplace to hold private keys, but that is off topic.\n\n\n\nOn Fri, Jul 31, 2015 at 6:16 AM, Adam Back via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I think trust the data-center logic obviously fails, and I was talking\n\u003e about this scenario in the post you are replying to. You are trusting the\n\u003e data-center operator period. If one could trust data-centers to run\n\u003e verified code, to not get hacked, filter traffic, respond to court orders\n\u003e without notifying you etc that would be great but that's unfortunately not\n\u003e what happens.\n\u003e\n\u003e Data-center operators are bound to follow laws, including NSLs and gag\n\u003e orders. They also get hacked, employ humans who can be corrupt,\n\u003e blackmailed, and themselves centralisation points for policy attack.\n\u003e Snowden related disclosures and keeping aware of security show this is very\n\u003e real.\n\u003e\n\u003e This isn't much about bitcoin even, its just security reality for hosting\n\u003e anything intended to be secure via decentralisation, or just hosting in\n\u003e general while at risk of political or policy attack.\n\u003e\n\u003e Adam\n\u003e On Jul 31, 2015 10:39, \"jl2012 via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e There is a summary of the proposals in my previous mail at\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009808.html\n\u003e\u003e\n\u003e\u003e I think there could be a compromise between Gavin's BIP101 and Pieter's\n\u003e\u003e proposal (called \"BIP103\" here). Below I'm trying to play with the\n\u003e\u003e parameters, which reasons:\n\u003e\u003e\n\u003e\u003e 1. Initiation: BIP34 style voting, with support of 750 out of the last\n\u003e\u003e 1000 blocks. The \"hardfork bit\" mechanism might be used:\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html\n\u003e\u003e\n\u003e\u003e Rationale: This follows BIP101, to make sure the new chain is secure.\n\u003e\u003e Also, no miner would like to be the first one to mine a large block if they\n\u003e\u003e don't know how many others would accept it.\n\u003e\u003e\n\u003e\u003e 2. Starting date: 30 days after 75% miner support, but not before\n\u003e\u003e 2016-01-12 00:00 UTC\n\u003e\u003e\n\u003e\u003e Rationale: A 30-day grace period is given to make sure everyone has\n\u003e\u003e enough time to follow. This is a compromise between 14 day in BIP101 and 1\n\u003e\u003e year in BIP103. I tend to agree with BIP101. Even 1 year is given, people\n\u003e\u003e will just do it on the 364th day if they opt to procrastinate.\n\u003e\u003e\n\u003e\u003e 2016-01-12 00:00 UTC is Monday evening in US and Tuesday morning in\n\u003e\u003e China. Most pool operators and devs should be back from new year holiday\n\u003e\u003e and not sleeping. (If the initiation is delayed, we may require that it\n\u003e\u003e must be UTC Tuesday midnight)\n\u003e\u003e\n\u003e\u003e 3. The block size at 2016-01-12 will be 1,414,213 bytes, and multiplied\n\u003e\u003e by 1.414213 by every 2^23 seconds (97 days) until exactly 8MB is reached on\n\u003e\u003e 2017-05-11.\n\u003e\u003e\n\u003e\u003e Rationale: Instead of jumping to 8MB, I suggest to increase it gradually\n\u003e\u003e to 8MB in 16 months. 8MB should not be particularly painful to run even\n\u003e\u003e with current equipment (you may see my earlier post on bitctointalk:\n\u003e\u003e https://bitcointalk.org/index.php?topic=1054482.0). 8MB is also agreed\n\u003e\u003e by Chinese miners, who control \u003e60% of the network.\n\u003e\u003e\n\u003e\u003e 4. After 8MB is reached, the block size will be increased by 6.714% every\n\u003e\u003e 97 days, which is equivalent to exactly octuple (8x) every 8.5 years, or\n\u003e\u003e double every 2.9 years, or +27.67% per year. Stop growth at 4096MB on\n\u003e\u003e 2042-11-17.\n\u003e\u003e\n\u003e\u003e Rationale: This is a compromise between 17.7% p.a. of BIP103 and 41.4%\n\u003e\u003e p.a. of BIP101. This will take us almost 8 years from now just to go back\n\u003e\u003e to the original 32MB size (4 years for BIP101 and 22 years for BIP103)\n\u003e\u003e\n\u003e\u003e SSD price is expected to drop by \u003e50%/year in the coming years. In 2020,\n\u003e\u003e we will only need to pay 2% of current price for SSD. 98% price reduction\n\u003e\u003e is enough for 40 years of 27.67% growth.\n\u003e\u003e Source:\n\u003e\u003e http://wikibon.org/wiki/v/Evolution_of_All-Flash_Array_Architectures\n\u003e\u003e\n\u003e\u003e Global bandwidth is expected to grow by 37%/year until 2021 so 27.67%\n\u003e\u003e should be safe at least for the coming 10 years.\n\u003e\u003e Source:\n\u003e\u003e https://www.telegeography.com/research-services/global-bandwidth-forecast-service/\n\u003e\u003e\n\u003e\u003e The final cap is a compromise between 8192MB at 2036 of BIP101 and\n\u003e\u003e 2048MB at 2063 of BIP103\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e -----------------------------------\n\u003e\u003e\n\u003e\u003e Generally speaking, I think we need to have a faster growth in the\n\u003e\u003e beginning, just to normalize the block size to a more reasonable one. After\n\u003e\u003e all, the 1MB cap was introduced when Bitcoin was practically worthless and\n\u003e\u003e with inefficient design. We need to decide a new \"optimal\" size based on\n\u003e\u003e current adoption and technology.\n\u003e\u003e\n\u003e\u003e About \"fee market\": I do agree we need a fee market, but the fee pressure\n\u003e\u003e must not be too high at this moment when block reward is still miner's main\n\u003e\u003e income source. We already have a fee market: miners will avoid building big\n\u003e\u003e blocks with low fee because that will increase the orphan risk for nothing.\n\u003e\u003e\n\u003e\u003e About \"secondary layer\": I respect everyone building secondary layer over\n\u003e\u003e the blockchain. However, while the SWIFT settlement network is processing\n\u003e\u003e 300tps, Bitcoin's current 7tps is just nothing more than an experiment. If\n\u003e\u003e the underlying settlement system does not have enough capacity, any\n\u003e\u003e secondary layer built on it will also fall apart. For example, people may\n\u003e\u003e DoS attack a Lightening network by provoking a huge amount of settlement\n\u003e\u003e request which some may not be confirmed on time. Ultimately, this will\n\u003e\u003e increase the risk of running a LN service and increase the tx fee inside\n\u003e\u003e LN. After all, the value of secondary layer primarily comes from instant\n\u003e\u003e confirmation, not scarcity of the block space.\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\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/20150731/faab5248/attachment.html\u003e",
"sig": "afd6ae1dedd91c091c1161ba617cf6b61d45d4482f0562c23612b20eb3ecf2dc4d2413340bc6ed6e6aa6f42ebf9a16acb81938437eabba5c35e5e638a9313091"
}