đź“… Original date posted:2014-05-18
đź“ť Original message:Now you are talking about Trusted Platform Modules. Like smartcards,
actually. Devices that won't leak their keys but let the holder spend the
coins. It could even have it's own simple SPV wallet client to make it
easier to handle. And they'd use the attestation features provided by the
TPM to prove the software it's unmodified top the current holder.
But then you still have to trust the manufacturer of the device, and you
have to trust it has no exploitable side channels.
- Sent from my phone
Den 18 maj 2014 13:52 skrev "Alex Kotenko" <alexykot at gmail.com>:
> I had a long discussion recently with somebody who wants and has resources
> to do exactly this - paper currency representing bitcoins. Yet we've been
> thinking mostly about a centralized solution, where one party is producing
> and maintaining paper currency, with bitcoins tied to each note verifiable
> via blockchain.
>
> The points we've ended up is that it needs to be:
> - reloadable
> - NFC based
> So anybody can verify any notes instantly by just touching it with his
> phone, and so merchants could redeem the notes at the moment of accepting
> it, convert it into fully online bitcoins and avoid costs of maintaining
> paper money turnover. Probably merchant would sell back redeemed
> empty notes to the issuer for a price of the note issue, and issuer will
> recharge it and put back into circulation.
>
> One problem we couldn't figure out here though - how to protect the notes
> from unauthorized redeem. Like if someone else tries to reach your wallet
> with his own NFC - how can we distinguish between deliberate redeem by
> owner and fraudulent redeem by anybody else with custom built long
> range NFC antenna? Any ideas?
>
>
> Best regards,
> Alex Kotenko
>
>
> 2014-05-17 17:40 GMT+01:00 Gregory Maxwell <gmaxwell at gmail.com>:
>
>> On Sat, May 17, 2014 at 9:07 AM, Chris Pacia <ctpacia at gmail.com> wrote:
>> > I can't really just hand someone the note and walk away
>> > because they have to scan it to see if it is actually valid.
>>
>> Not just scan it, but they actually must successfully sweep it—
>> otherwise they can be trivially double spent. This is especially bad
>> since any prior bearer can perform such an attack. E.g. record the
>> private key of everyone that passes through your hands and then
>> doublespend race any redemption that happens >24 hours after you spend
>> them. The wrong person would likely be blamed and even if you were
>> blamed you could plausibly deny it ("Must have been the guy that gave
>> it to me!").
>>
>> Othercoin seems to have much better properties in the space of offline
>> transactions: https://bitcointalk.org/index.php?topic=319146.0
>>
>> Separately, Cassius also ran into some regulatory issues selling
>> physical bitcoin artifacts. Especially printing things that seem to be
>> redeemable for a named USD value sounds especially problematic.
>>
>> Some random comments— The base58 encoding is fairly human unfriendly.
>> It's fine for something being copy and pasted, but I've found typing
>> or reading it works poorly due to mixed case. I expect the A/B side
>> to be difficult to educate users about. "This side is private" is more
>> easily understood, you could just pick one of your sides and call it
>> private. I find it kind of odd that this design seems to have no
>> facility for checking its txouts without recovering the private key,
>> though considering no one should rely on such a measurement without
>> sweeping perhaps thats for the best.
>>
>> (As far as the numbering goes, I think you should be calling these
>> draft-felix-paper-currency etc. As a matter of hygienic practice I
>> will not assign a matching bip number for something that went public
>> with a number outside of the assignment.)
>>
>>
>> ------------------------------------------------------------------------------
>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
>> Instantly run your Selenium tests across 300+ browser/OS combos.
>> Get unparalleled scalability from the best Selenium testing platform
>> available
>> Simple to use. Nothing to install. Get started now for free."
>> http://p.sf.net/sfu/SauceLabs
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/62c97e9d/attachment.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 15:21:35
in reply to nevent1q…rzsu
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 15:21:35Event JSON
{
"id": "569c9d699b9fd97f3d3e93081ff5035fd6c3361a4a624c0ad1c8808c3328f6f0",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686151295,
"kind": 1,
"tags": [
[
"e",
"d30b28e456bef274130eabcfd37469931101e35cbb7eae21abca740750812e9b",
"",
"root"
],
[
"e",
"fd8ad612c81579b0b0853ebececa15cf330f8c81c0a594cb0e8d6838fb71ae56",
"",
"reply"
],
[
"p",
"ac99e5ca3122fca258fbfcb6cb62d10d4dba423b3243251cbc0c4e0042656dec"
]
],
"content": "📅 Original date posted:2014-05-18\n📝 Original message:Now you are talking about Trusted Platform Modules. Like smartcards,\nactually. Devices that won't leak their keys but let the holder spend the\ncoins. It could even have it's own simple SPV wallet client to make it\neasier to handle. And they'd use the attestation features provided by the\nTPM to prove the software it's unmodified top the current holder.\n\nBut then you still have to trust the manufacturer of the device, and you\nhave to trust it has no exploitable side channels.\n\n- Sent from my phone\nDen 18 maj 2014 13:52 skrev \"Alex Kotenko\" \u003calexykot at gmail.com\u003e:\n\n\u003e I had a long discussion recently with somebody who wants and has resources\n\u003e to do exactly this - paper currency representing bitcoins. Yet we've been\n\u003e thinking mostly about a centralized solution, where one party is producing\n\u003e and maintaining paper currency, with bitcoins tied to each note verifiable\n\u003e via blockchain.\n\u003e\n\u003e The points we've ended up is that it needs to be:\n\u003e - reloadable\n\u003e - NFC based\n\u003e So anybody can verify any notes instantly by just touching it with his\n\u003e phone, and so merchants could redeem the notes at the moment of accepting\n\u003e it, convert it into fully online bitcoins and avoid costs of maintaining\n\u003e paper money turnover. Probably merchant would sell back redeemed\n\u003e empty notes to the issuer for a price of the note issue, and issuer will\n\u003e recharge it and put back into circulation.\n\u003e\n\u003e One problem we couldn't figure out here though - how to protect the notes\n\u003e from unauthorized redeem. Like if someone else tries to reach your wallet\n\u003e with his own NFC - how can we distinguish between deliberate redeem by\n\u003e owner and fraudulent redeem by anybody else with custom built long\n\u003e range NFC antenna? Any ideas?\n\u003e\n\u003e\n\u003e Best regards,\n\u003e Alex Kotenko\n\u003e\n\u003e\n\u003e 2014-05-17 17:40 GMT+01:00 Gregory Maxwell \u003cgmaxwell at gmail.com\u003e:\n\u003e\n\u003e\u003e On Sat, May 17, 2014 at 9:07 AM, Chris Pacia \u003cctpacia at gmail.com\u003e wrote:\n\u003e\u003e \u003e I can't really just hand someone the note and walk away\n\u003e\u003e \u003e because they have to scan it to see if it is actually valid.\n\u003e\u003e\n\u003e\u003e Not just scan it, but they actually must successfully sweep it—\n\u003e\u003e otherwise they can be trivially double spent. This is especially bad\n\u003e\u003e since any prior bearer can perform such an attack. E.g. record the\n\u003e\u003e private key of everyone that passes through your hands and then\n\u003e\u003e doublespend race any redemption that happens \u003e24 hours after you spend\n\u003e\u003e them. The wrong person would likely be blamed and even if you were\n\u003e\u003e blamed you could plausibly deny it (\"Must have been the guy that gave\n\u003e\u003e it to me!\").\n\u003e\u003e\n\u003e\u003e Othercoin seems to have much better properties in the space of offline\n\u003e\u003e transactions: https://bitcointalk.org/index.php?topic=319146.0\n\u003e\u003e\n\u003e\u003e Separately, Cassius also ran into some regulatory issues selling\n\u003e\u003e physical bitcoin artifacts. Especially printing things that seem to be\n\u003e\u003e redeemable for a named USD value sounds especially problematic.\n\u003e\u003e\n\u003e\u003e Some random comments— The base58 encoding is fairly human unfriendly.\n\u003e\u003e It's fine for something being copy and pasted, but I've found typing\n\u003e\u003e or reading it works poorly due to mixed case. I expect the A/B side\n\u003e\u003e to be difficult to educate users about. \"This side is private\" is more\n\u003e\u003e easily understood, you could just pick one of your sides and call it\n\u003e\u003e private. I find it kind of odd that this design seems to have no\n\u003e\u003e facility for checking its txouts without recovering the private key,\n\u003e\u003e though considering no one should rely on such a measurement without\n\u003e\u003e sweeping perhaps thats for the best.\n\u003e\u003e\n\u003e\u003e (As far as the numbering goes, I think you should be calling these\n\u003e\u003e draft-felix-paper-currency etc. As a matter of hygienic practice I\n\u003e\u003e will not assign a matching bip number for something that went public\n\u003e\u003e with a number outside of the assignment.)\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e \"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE\n\u003e\u003e Instantly run your Selenium tests across 300+ browser/OS combos.\n\u003e\u003e Get unparalleled scalability from the best Selenium testing platform\n\u003e\u003e available\n\u003e\u003e Simple to use. Nothing to install. Get started now for free.\"\n\u003e\u003e http://p.sf.net/sfu/SauceLabs\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE\n\u003e Instantly run your Selenium tests across 300+ browser/OS combos.\n\u003e Get unparalleled scalability from the best Selenium testing platform\n\u003e available\n\u003e Simple to use. Nothing to install. Get started now for free.\"\n\u003e http://p.sf.net/sfu/SauceLabs\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140518/62c97e9d/attachment.html\u003e",
"sig": "49081b711b98e45abdb1807a1489d49d650ce2ee01bd14c9c1a8fd03767237d0617af58969e5bb92b0ef03a2e2bbe6a0fc99052d6dd270eeb166ada7ccdcd5cf"
}