Gregory Maxwell [ARCHIVE] on Nostr: đź“… Original date posted:2012-10-09 đź“ť Original message:On Mon, Oct 8, 2012 at ...
đź“… Original date posted:2012-10-09
đź“ť Original message:On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn <mike at plan99.net> wrote:
> I don't think it's worth worrying about this too much right now. In
> future the software end users and merchants use will diverge
> significantly.
Electrum also has a daemon for merchants. Considering the dislike of
Java that exist reflexively in much of the non-java community and the
greater ease of deployment and the integration of type-2 split key
management, I wouldn't be surprised if it became quite popular
quickly especially if the status quo of failing to disclose and
discuss the security limitations of the client continues.
What I've found is that even fairly sophisticated bitcoin participants
are actually unaware of the security implications— not just of thin
clients architecturally but of electrum specifically. I think even
you may find my findings of the latter a bit surprising.
Generally for thin clients— a lying server can make clients think
they've received confirmed payments they haven't, and unless the
client is constructed to be a bit less thin a lying server can lie
about input values and cause think clients to spend large values to
fees. Servers can also monitor clients and deanonymize them and
selectively deny service to particular clients or transactions. Thin
clients must trust their servers to be available, and to not perform
these attacks. Users can use tools like tor to reduce the privacy
attacks, but doing so inhibits having a trust relationship to protect
against the other attacks. And none of these attacks leave
cryptographic proof of their existence, so a victim can't convince the
public of a server's treachery. Us experts know about these risks, but
I don't think the general users do.
But thats not the limit of it— It seems some people believe Electrum
does majority quorum between servers, complicating attacks arising
from the fact that today users virtually never have a reason to trust
their server operators. This isn't true— it connect to one at a time.
(And sibyl attacks would make that pretty weak protection even if it
did that, as someone could use a a botnet to run tens of thousands of
'servers' (really proxies)).
Beyond that the protocol between the clients and servers is
unauthenticated cleartext JSON in TCP. So any network advisory with
access to the network near the server has the same power to attack as
the server operator... and one near the client has the same power to
attack as the sum of all the server operators. A passive attacker
near the client has full deanonymization power.
But I don't even know if any of these limitations matter much— The
electrum client instantly displays unconfirmed transactions and allows
users to spend them. The default user interface gives _no_ indication
that the payment is unconfirmed. There is a "pro" mode, that shows
'processing' for unconfirmed transactions... but it looks as final as
it ever will be once it gets a single confirm. Only the most cautious
and well informed users would open the pro interface and right click
and select details to see the count— and even then there is no
guidance on what numbers are good (beyond '1'). So I suspect people
can probably rob typical electrum users (including electrum running
merchants) without actually using any of the above.
When a thin client is willing to provide arbitrary features like
showing unconfirmed payments and simplified UI without regard to
security it removes the functional advantage of running more secure
software like SPV and various degrees of full node... the only
motivation is security, and it's not much of a motivation when the
risks aren't even disclosed.
...and I haven't even gotten into delving into what kind of attacks
are possible due to deeper implementation specifics.
But I do share your view that people will migrate to stronger client
models in the future— but I don't agree that it will be due to those
clients improving (though they will improve), it will be because
people will know that they provide better security and will choose
them for that reason.
My only question is will they know this because we as a community and
the authors of the thin clients provided clear explanations and
appropriate caution, or will it be because they're getting robbed
blind, producing a bunch of bad press for thin clients in particular
and Bitcoin generally?
Published at
2023-06-07 10:34:54Event JSON
{
"id": "7794ca9fe6ac9dd18b57c45a8a972ca3bd9de257899b8352c9b0f07ee12d9157",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686134094,
"kind": 1,
"tags": [
[
"e",
"6605d854c6e4f4272cbe29970c1fc384bdd30dc3dd6abee124159a3b84ca05c1",
"",
"root"
],
[
"e",
"3e0c69c2c82c2ec1e90a88b9e9638cfb3bcdca11a16dff3aeb06fbf617538e02",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-10-09\n📝 Original message:On Mon, Oct 8, 2012 at 7:52 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e I don't think it's worth worrying about this too much right now. In\n\u003e future the software end users and merchants use will diverge\n\u003e significantly.\n\nElectrum also has a daemon for merchants. Considering the dislike of\nJava that exist reflexively in much of the non-java community and the\ngreater ease of deployment and the integration of type-2 split key\nmanagement, I wouldn't be surprised if it became quite popular\nquickly especially if the status quo of failing to disclose and\ndiscuss the security limitations of the client continues.\n\nWhat I've found is that even fairly sophisticated bitcoin participants\nare actually unaware of the security implications— not just of thin\nclients architecturally but of electrum specifically. I think even\nyou may find my findings of the latter a bit surprising.\n\nGenerally for thin clients— a lying server can make clients think\nthey've received confirmed payments they haven't, and unless the\nclient is constructed to be a bit less thin a lying server can lie\nabout input values and cause think clients to spend large values to\nfees. Servers can also monitor clients and deanonymize them and\nselectively deny service to particular clients or transactions. Thin\nclients must trust their servers to be available, and to not perform\nthese attacks. Users can use tools like tor to reduce the privacy\nattacks, but doing so inhibits having a trust relationship to protect\nagainst the other attacks. And none of these attacks leave\ncryptographic proof of their existence, so a victim can't convince the\npublic of a server's treachery. Us experts know about these risks, but\nI don't think the general users do.\n\nBut thats not the limit of it— It seems some people believe Electrum\ndoes majority quorum between servers, complicating attacks arising\nfrom the fact that today users virtually never have a reason to trust\ntheir server operators. This isn't true— it connect to one at a time.\n(And sibyl attacks would make that pretty weak protection even if it\ndid that, as someone could use a a botnet to run tens of thousands of\n'servers' (really proxies)).\n\nBeyond that the protocol between the clients and servers is\nunauthenticated cleartext JSON in TCP. So any network advisory with\naccess to the network near the server has the same power to attack as\nthe server operator... and one near the client has the same power to\nattack as the sum of all the server operators. A passive attacker\nnear the client has full deanonymization power.\n\nBut I don't even know if any of these limitations matter much— The\nelectrum client instantly displays unconfirmed transactions and allows\nusers to spend them. The default user interface gives _no_ indication\nthat the payment is unconfirmed. There is a \"pro\" mode, that shows\n'processing' for unconfirmed transactions... but it looks as final as\nit ever will be once it gets a single confirm. Only the most cautious\nand well informed users would open the pro interface and right click\nand select details to see the count— and even then there is no\nguidance on what numbers are good (beyond '1'). So I suspect people\ncan probably rob typical electrum users (including electrum running\nmerchants) without actually using any of the above.\n\nWhen a thin client is willing to provide arbitrary features like\nshowing unconfirmed payments and simplified UI without regard to\nsecurity it removes the functional advantage of running more secure\nsoftware like SPV and various degrees of full node... the only\nmotivation is security, and it's not much of a motivation when the\nrisks aren't even disclosed.\n\n...and I haven't even gotten into delving into what kind of attacks\nare possible due to deeper implementation specifics.\n\nBut I do share your view that people will migrate to stronger client\nmodels in the future— but I don't agree that it will be due to those\nclients improving (though they will improve), it will be because\npeople will know that they provide better security and will choose\nthem for that reason.\n\nMy only question is will they know this because we as a community and\nthe authors of the thin clients provided clear explanations and\nappropriate caution, or will it be because they're getting robbed\nblind, producing a bunch of bad press for thin clients in particular\nand Bitcoin generally?",
"sig": "81c1aa2a4a05532d1720446918736ec3831635b803798ad0c2ad4ed3d7fc444fdc35be34e2173b9d21442862b2a048b42c32c06963e89ba1c9b06b517e077c5a"
}