š
Original date posted:2014-04-10
š Original message:You took the quote out of context:
"a full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work) commits to a valid
UTXO set (at some point in the past)."
The described synchronization mechanism would be to determine the
most-work block header (SPV level of security!), and then sync the UTXO
set committed to within that block. This is strictly less security than
building the UTXO set yourself because it is susceptible to a 51% attack
which violates protocol rules.
On 04/10/2014 11:19 AM, Paul Rabahy wrote:
> You say UTXO commitments is "a strict reduction in security". If UTXO
> commitments were rolled in as a soft fork, I do not see any new attacks
> that could happen to a person trusting the committed UTXO + any
> remaining blocks to catch up to the head.
>
> I would imagine the soft fork to proceed similar to the following.
> 1. Miners begin including UTXO commitments.
> 2. Miners begin rejecting blocks with invalid UTXO commitments.
> 3. Miners begin rejecting blocks with no UTXO commitments.
>
> To start up a fresh client it would follow the following.
> 1. Sync headers.
> 2. Pick a committed UTXO that is deep enough to not get orphaned.
> 3. Sync blocks from commitment to head.
>
> I would argue that a client following this methodology is strictly more
> secure than SPV, and I don't see any attacks that make it less secure
> than a full client. It is obviously still susceptible to a 51% attack,
> but so is the traditional block chain. I also do not see any sybil
> attacks that are strengthened by this change because it is not modifying
> the networking code.
>
> I guess if the soft fork happened, then miners began to not include the
> UTXO commitment anymore, it would lower the overall network hash rate,
> but this would be self-harming to the miners so they have an incentive
> to not do it.
>
> Please let me know if I have missed something.
Mark Friedenbach [ARCHIVE] /
npub1r3ā¦48d0u
2023-06-07 15:18:32
in reply to nevent1qā¦26a7
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:18:32Event JSON
{
"id": "b0b9007b9e855030f48fe57ca2df01b7f453a5550fd044d5a0494b4fe234cf58",
"pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069",
"created_at": 1686151112,
"kind": 1,
"tags": [
[
"e",
"aae8a2dedee78eef571f285fef23331d89c84b104c87b098618414541001d13e",
"",
"root"
],
[
"e",
"0a0ceac345964e1bb393e20cdd6f4783d6dcc264bd1926865fa095756f682d6d",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "š
Original date posted:2014-04-10\nš Original message:You took the quote out of context:\n\n\"a full node can copy the chain state from someone else, and check that\nits hash matches what the block chain commits to. It's important to\nnote that this is a strict reduction in security: we're now trusting\nthat the longest chain (with most proof of work) commits to a valid\nUTXO set (at some point in the past).\"\n\nThe described synchronization mechanism would be to determine the\nmost-work block header (SPV level of security!), and then sync the UTXO\nset committed to within that block. This is strictly less security than\nbuilding the UTXO set yourself because it is susceptible to a 51% attack\nwhich violates protocol rules.\n\nOn 04/10/2014 11:19 AM, Paul Rabahy wrote:\n\u003e You say UTXO commitments is \"a strict reduction in security\". If UTXO\n\u003e commitments were rolled in as a soft fork, I do not see any new attacks\n\u003e that could happen to a person trusting the committed UTXO + any\n\u003e remaining blocks to catch up to the head.\n\u003e \n\u003e I would imagine the soft fork to proceed similar to the following.\n\u003e 1. Miners begin including UTXO commitments.\n\u003e 2. Miners begin rejecting blocks with invalid UTXO commitments.\n\u003e 3. Miners begin rejecting blocks with no UTXO commitments.\n\u003e \n\u003e To start up a fresh client it would follow the following.\n\u003e 1. Sync headers.\n\u003e 2. Pick a committed UTXO that is deep enough to not get orphaned.\n\u003e 3. Sync blocks from commitment to head.\n\u003e \n\u003e I would argue that a client following this methodology is strictly more\n\u003e secure than SPV, and I don't see any attacks that make it less secure\n\u003e than a full client. It is obviously still susceptible to a 51% attack,\n\u003e but so is the traditional block chain. I also do not see any sybil\n\u003e attacks that are strengthened by this change because it is not modifying\n\u003e the networking code.\n\u003e \n\u003e I guess if the soft fork happened, then miners began to not include the\n\u003e UTXO commitment anymore, it would lower the overall network hash rate,\n\u003e but this would be self-harming to the miners so they have an incentive\n\u003e to not do it.\n\u003e \n\u003e Please let me know if I have missed something.",
"sig": "e01ebd583c088ac3de9aa3de79d84d16dcef648f0c0619bde2d93585240bb0cc3280b63256e2d70baa48d6cea7f5c68591c4e7e7d6b11df02b2ff1527e3d5a22"
}