đź“… Original date posted:2017-03-07
đź“ť Original message:> Bitcoin would lose the security and in the short term even the ability to
mine blocks every 10 minutes.
Presumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset. There's really little difference between 10 minutes at little/no security and zero conf. See testnet. But people might feel better about still seeing blocks.
But in any case it's not clear to me why you assume a loss of security in the "short term" is something that can be overcome. The short term can presumably prevent the long term from ever becoming.
e
> On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
>> What you're describing is a hashpower activated soft fork to censor
>> transactions, in response to a user activated soft fork that the majority
>> of hashpower disagrees with.
>
> It is incorrect to say that censoring of transactions is what Edmund
> suggested. It's purely about the form they take, you can re-send the
> transaction in a different form with the same content and they go through.
> Hence, not transaction censoring.
>
> I do believe the point that Edmund brought up is a very good one, the idea
> that a set of users can force the miners to do something is rather silly and
> the setup that a minority miner fraction can force the majority to do
> something is equally silly. This is because the majority mining hashpower
> can fight back against this attack upon them.
>
> Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we’d see governments try to push
> through changes in the same UASF way. I’m very happy that UASFs can’t work
> because that would be the end of Bitcoin's freedom and decentralized nature.
>
>> It is always possible for a majority of hashpower to censor transactions
>> they disagree with. Users may view that as an attack, and can always
>> respond with a POW hard fork.
>
> I definitely welcome that approach.
>
> The result would be that you have two chains, but also you ensure that the
> chain that the miners didn’t like will no longer be something they can mine.
> Not even the minority set of miners that like the softfork can mine on it.
> This is a win-win and then the market will decide which one will "win".
>
>> Bitcoin only works if the majority of hashpower is not hostile to the
>> users.
>
> This goes both ways, miners both generate value (in the form of security)
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners
> create, or change the POW, then what the miners bring to the table is also
> removed.
> Bitcoin would lose the security and in the short term even the ability to
> mine blocks every 10 minutes.
>
> So, lets correct your statement a little;
> «Bitcoin only works when the majority of the hashpower and the (economic)
> majority of the users are balanced in power and have their goals aligned.»
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 17:57:05
in reply to nevent1q…frtd
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 17:57:05Event JSON
{
"id": "bfe7487d4c4445409c16e47e1dcac1ea1dbef15bfdff356563ab37eddab7a1e7",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686160625,
"kind": 1,
"tags": [
[
"e",
"884240603140ed27b03f27320d4379ba808b85a816007fd6f0068a3a767a99ca",
"",
"root"
],
[
"e",
"0160fef19b4e286120a7cead5693186a7acaff27817115522e1e3ea79b9a7a14",
"",
"reply"
],
[
"p",
"dcb947d818dbfd7cf0baf26c0d5eb606b5a32336c5483fb53e05146315833ca7"
]
],
"content": "📅 Original date posted:2017-03-07\n📝 Original message:\u003e Bitcoin would lose the security and in the short term even the ability to \nmine blocks every 10 minutes.\n\nPresumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset. There's really little difference between 10 minutes at little/no security and zero conf. See testnet. But people might feel better about still seeing blocks.\n\nBut in any case it's not clear to me why you assume a loss of security in the \"short term\" is something that can be overcome. The short term can presumably prevent the long term from ever becoming.\n\ne\n\n\u003e On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:\n\u003e\u003e What you're describing is a hashpower activated soft fork to censor\n\u003e\u003e transactions, in response to a user activated soft fork that the majority\n\u003e\u003e of hashpower disagrees with.\n\u003e \n\u003e It is incorrect to say that censoring of transactions is what Edmund \n\u003e suggested. It's purely about the form they take, you can re-send the \n\u003e transaction in a different form with the same content and they go through. \n\u003e Hence, not transaction censoring.\n\u003e \n\u003e I do believe the point that Edmund brought up is a very good one, the idea \n\u003e that a set of users can force the miners to do something is rather silly and \n\u003e the setup that a minority miner fraction can force the majority to do \n\u003e something is equally silly. This is because the majority mining hashpower \n\u003e can fight back against this attack upon them.\n\u003e \n\u003e Don’t be mistaken; a hash-minority attacking the hash-majority is in actual \n\u003e fact an attack upon Bitcoin as a whole.\n\u003e If this were possible then next year we’d see governments try to push \n\u003e through changes in the same UASF way. I’m very happy that UASFs can’t work \n\u003e because that would be the end of Bitcoin's freedom and decentralized nature.\n\u003e \n\u003e\u003e It is always possible for a majority of hashpower to censor transactions\n\u003e\u003e they disagree with. Users may view that as an attack, and can always\n\u003e\u003e respond with a POW hard fork.\n\u003e \n\u003e I definitely welcome that approach.\n\u003e \n\u003e The result would be that you have two chains, but also you ensure that the \n\u003e chain that the miners didn’t like will no longer be something they can mine. \n\u003e Not even the minority set of miners that like the softfork can mine on it. \n\u003e This is a win-win and then the market will decide which one will \"win\".\n\u003e \n\u003e\u003e Bitcoin only works if the majority of hashpower is not hostile to the\n\u003e\u003e users.\n\u003e \n\u003e This goes both ways, miners both generate value (in the form of security) \n\u003e and they take value (in the form of inflation).\n\u003e If the majority of the users are hostile and reject blocks that the miners \n\u003e create, or change the POW, then what the miners bring to the table is also \n\u003e removed.\n\u003e Bitcoin would lose the security and in the short term even the ability to \n\u003e mine blocks every 10 minutes.\n\u003e \n\u003e So, lets correct your statement a little;\n\u003e «Bitcoin only works when the majority of the hashpower and the (economic)\n\u003e majority of the users are balanced in power and have their goals aligned.»\n\u003e \n\u003e -- \n\u003e Tom Zander\n\u003e Blog: https://zander.github.io\n\u003e Vlog: https://vimeo.com/channels/tomscryptochannel\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",
"sig": "1dfbc11f76115a1ec34b6cfd64f759af520d3faa532e1e9e1a18c8ed3b029de8343b18e0c00cf2f60aec4f342e4141e26feb64f55ea62cec729d4a7178f2aaa4"
}