📅 Original date posted:2015-12-17
📝 Original message:This is not correct.
As only about 1/3 of nodes support BIP65 now, would you consider CLTV tx
are less secure than others? I don't think so. Since one invalid CLTV tx
will make the whole block invalid. Having more nodes to fully validate
non-CLTV txs won't make them any safer. The same logic also applies to
SW softfork.
You may argue that a softfork would make the network as a whole less
secure, as old nodes have to trust new nodes. However, the security of
all content in the same block must be the same, by definition.
Anyway, I support SW softfork at the beginning, and eventually (~2
years) moving to a hardfork with higher block size limit and better
commitment structure.
Jeff Garzik via bitcoin-dev 於 2015-12-17 13:27 寫到:
>
> Illustration: If SW is deployed via soft fork, the count of nodes
> that validate witness data is significantly lower than the count of
> nodes that validate non-witness data. Soft forks are not trustless
> operation, they depend on miner trust, slowly eroding the trustless
> validation of older nodes over time.
>
> Higher security in one data area versus another produces another
> economic value distinction between the two goods in the basket, and
> creates a "pay more for higher security in core block, pay less for
> lower security in witness" dynamic.
>
> This economic distinction is not present if SW is deployed via hard
> fork.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
jl2012 [ARCHIVE] /
npub14v…jyksm
2023-06-07 17:46:41
in reply to nevent1q…tcjd
Author Public Key
npub14vwgt02663pkxx54kg5t693shaavmvnldhsp49sve7asw7p36lkqljyksmPublished at
2023-06-07 17:46:41Event JSON
{
"id": "11ef46f52b7451950195af341c6616d49764fda4f2e50d1b8a4ebebca4f50920",
"pubkey": "ab1c85bd5ad443631a95b228bd1630bf7acdb27f6de01a960ccfbb077831d7ec",
"created_at": 1686160001,
"kind": 1,
"tags": [
[
"e",
"46b1d48aa4e00b636e8dc4e9c37e717542bb528954bcd46114dd6b14e1119e69",
"",
"root"
],
[
"e",
"8ea1a950d0dd9a8685fd52aedd2e7717794498cb7be5f90fd17d62344d019d42",
"",
"reply"
],
[
"p",
"b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11"
]
],
"content": "📅 Original date posted:2015-12-17\n📝 Original message:This is not correct.\n\nAs only about 1/3 of nodes support BIP65 now, would you consider CLTV tx \nare less secure than others? I don't think so. Since one invalid CLTV tx \nwill make the whole block invalid. Having more nodes to fully validate \nnon-CLTV txs won't make them any safer. The same logic also applies to \nSW softfork.\n\nYou may argue that a softfork would make the network as a whole less \nsecure, as old nodes have to trust new nodes. However, the security of \nall content in the same block must be the same, by definition.\n\nAnyway, I support SW softfork at the beginning, and eventually (~2 \nyears) moving to a hardfork with higher block size limit and better \ncommitment structure.\n\nJeff Garzik via bitcoin-dev 於 2015-12-17 13:27 寫到:\n\n\u003e \n\u003e Illustration: If SW is deployed via soft fork, the count of nodes\n\u003e that validate witness data is significantly lower than the count of\n\u003e nodes that validate non-witness data. Soft forks are not trustless\n\u003e operation, they depend on miner trust, slowly eroding the trustless\n\u003e validation of older nodes over time.\n\u003e \n\u003e Higher security in one data area versus another produces another\n\u003e economic value distinction between the two goods in the basket, and\n\u003e creates a \"pay more for higher security in core block, pay less for\n\u003e lower security in witness\" dynamic.\n\u003e \n\u003e This economic distinction is not present if SW is deployed via hard\n\u003e fork.\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",
"sig": "4dd7aeb4fde5c5f24ce22506e744dd33bd98bb003352406a76f4f63c7c044beb1bca5c5e11a0a71d5ede8fce89b99779f2400e03dfa194c81558fd4e43396c77"
}