fixed public key coin transfer (for zero-trust physical coin transfer)

[Sergio_Demian_Lerner]

Anyway, if you ask the firmcoin to sign a transaction, then it doesn't matter if it leaks all the private key, probably your transaction will get into a block before the attacker extracts the private-key, and creates his own competing transaction, which will be regarded as a double-spend attempt.

[1714713084]

1714713084

[1714713084]

1714713084

[1714713084]

1714713084

[1714713084]

1714713084

[1714713084]

1714713084

[adam3us]

Maybe to the limited extent of the tamper resistance, tamper evidence, an holograms etc that some people may want to trust that, we could have both objectives in one coin (moderately safe for offline transfer AND new owner chooses part of the key).  And Sergio Lerner said something like this:

Because I knew about side channel attacks, I preferred that the firmcoin do not sign anything that goes out to the Internet. The firmware just gives you the private key whenever you want, but at the same time it enters  a special "empty" state, where it no longer advertises as a funded device.

Alright - sounds like you know what you're doing - you went for the plan A.

You either need to not trust the hardware to make the signature, or you need the DSA subliminal channel to be plugged.

That aspect was unclear from your description before, but that is a consistent and reasonable design.

Also the day a counterfeit device appears on the market, from that day on the firmcoins will no longer be able to be verified off-line, but that doesn´t mean they are useless. They still can be extracted their private keys. They can be reloaded and uses as BTC storage. So the incentive to an attacker is very low: he can just steal some very few BTC until everybody knows there are counterfeit devices in the market. Who will invest in manufacturing a special chip for such a crappy attack?

Your use of x=yx' (y chosen by user) makes more sense in that context also, as then attacker cant mark coin public keys for transfers to coins (which will appear on the block chain).

btw As you have a funded state on the coin, and passive accumulated stray RF power possibility you could flash a light on button push to indicate green or red status even.

Any thoughts about suggestion to make the private key recoverable by combination of users retained (but not block chain published) y values (or other new value) and manufacturer on receipt of broken hardware?  May make it more attractive for bigger balances - otherwise I can see people being scared to put bigger amounts on it in case of hardware failure.  As is I could take the value off the card (empty state) for safe storage/backup/paper-wallet, but as soon as I reload the coin it chooses a new private key that I dont know, and cant easily know without resetting it back to empty state.

Adam

[Sergio_Demian_Lerner]

Your use of x=yx' (y chosen by user) makes more sense in that context also, as then attacker cant mark coin public keys for transfers to coins (which will appear on the block chain).

btw As you have a funded state on the coin, and passive accumulated stray RF power possibility you could flash a light on button push to indicate green or red status even.

Passive displays are very expensive. I found that the smallest eInk display costs 8 USD.
And a capacitor with a LED will hold the status not long enough.
A solar cell may work, but still they are expensive. I want the firmcoin to be under 3 USD.

Any thoughts about suggestion to make the private key recoverable by combination of users retained (but not block chain published) y values (or other new value) and manufacturer on receipt of broken hardware?  May make it more attractive for bigger balances - otherwise I can see people being scared to put bigger amounts on it in case of hardware failure.  As is I could take the value off the card (empty state) for safe storage/backup/paper-wallet, but as soon as I reload the coin it chooses a new private key that I dont know, and cant easily know without resetting it back to empty state.

One  possibility is that when the firmcoin generates a key pair X, and you generate another key pair Y.
You print the keypair Y in a QR code and stick QR code in the firmcoin. To load funds, you load them to a 2-2 multisig (a transaction that requires both private keys to sign the input).
The the firmcoin cannot by himself do anything to steal the coins, even leaking its private key is useless. The worst thing it can do is just stop working (which will make you loose your coins, but the attacker gains nothing).

The person who stamped the QR code must collude with the hardware manufacturer in order to create a firmcoin that can leak usefull information to stole the coins.
So if you stamp the QR code yourself, then the fircoin manufacturer still cannot steal your coins.

[Sergio_Demian_Lerner]

Also in a firmcoin there are two methods to reload coins:

1. You send the the pubkey to a Firmcoin server, and he server returns you a signed message that your Firmcoin verifies to and enters the "funded" state.

2. You provide the firmcoin with a block-chain branch of at least 144 blocks with the current difficulty, where the first block contains a transaction that funds the firmcoin, along with the merkle tree. If each block reward is 12 BTC, when you can fund upto N*12/2 BTC, where N is the size of the supplied chain, an N is at least 144. This can be done privately, and anonymously.

None of this methods has any security problem: if you receive a firmcoin, it's either authentic or not authentic (you check by eye inspection, and some other methods).
If it's authentic, either it has funded coins or it does not, and you can query the device for this information.

Sergio.

[adam3us]

btw As you have a funded state on the coin, and passive accumulated stray RF power possibility you could flash a light on button push to indicate green or red status even.

Passive displays are very expensive. I found that the smallest eInk display costs 8 USD.
And a capacitor with a LED will hold the status not long enough.

But arent there possibility to accumulate small amounts of power continuously from stray / background EM emission?  Perhaps not for $3?

A solar cell may work, but still they are expensive. I want the firmcoin to be under 3 USD.

Maybe I can shake the coin a bit and a led glows red or green   Not sure what linear micro generators cost.

Any thoughts about suggestion to make the private key recoverable by combination of users retained (but not block chain published) y values (or other new value) and manufacturer on receipt of broken hardware?

One  possibility is that when the firmcoin generates a key pair X, and you generate another key pair Y.
You print the keypair Y in a QR code and stick QR code in the firmcoin. To load funds, you load them to a 2-2 multisig (a transaction that requires both private keys to sign the input).
The the firmcoin cannot by himself do anything to steal the coins, even leaking its private key is useless. The worst thing it can do is just stop working (which will make you loose your coins, but the attacker gains nothing).

No what I was meaning is I am not worried about the manufacturer stealing coins (as the user controls the public address, and the coin not computing signatures has no subliminal channel other than NFC).

More worried that the coin dies when I drop it with 10BTC on it.  I do prefer the QR code to be embedded in the coin as you have it, stickers can rub off etc.

So eg say the coin encrypts x' with the manufacturers public key, preferably in a way verifiable to the user (user can verify if coin encrypted x' not x), sends E(x') to user.  User retains E(x') and y.  If the coin dies, the user sends the physical coin back to the manufacturer who computes x' and sends it to the user.  The manufacturer still doesnt know y so cant spend the coin.  The manufacturer only accepts physical coins so no one can easily trick the manfacturer into helping them recover coins from other users that they dont have physical possession of.  Manufacturer also cant remote invalidate coins.

Adam

[adam3us]

Also in a firmcoin there are two methods to reload coins:

1. You send the the pubkey to a Firmcoin server, and he server returns you a signed message that your Firmcoin verifies to and enters the "funded" state.

Why do you involve a firmcoin server?  Does that mean a firmcoin server retains the technical authority to falsely trigger a firmcoin to think its loaded?

Why not just pay to the address of the coin (which it knows), and then present it with a merkle tree containing the coin and a block with reasonable difficulty containing it.  As the coin knows it has sole control of the private key, it knows that the coin can not have been re-spent.

A verifier can then check the information against its view of the block-chain and validate for itself the merkle tree?

edit: I guess you're concerned that proper validation is too expensive for the coin, and you want some transferable representation of the fact a full node server (or even an SPV client) has validated the load transaction.   May also want to ideally avoid the need for the continued availability of the firmcoin server.  What happens if firmcoin goes out of business?  No more ability to re-load firmcoins?  Not obvious how to retain the loaded/empty distinction without a more powerful coin, or some entity to semi-trust.  You probably want to have the coin still check the block collision and merkle tree even with a firmcoin server signature.  (Firmcoin server could get hacked itself, and abused to load non-existing balance onto coins for offline spending).

Adam

[Sergio_Demian_Lerner]

Also in a firmcoin there are two methods to reload coins:

1. You send the the pubkey to a Firmcoin server, and he server returns you a signed message that your Firmcoin verifies to and enters the "funded" state.

Why do you involve a firmcoin server?  Does that mean a firmcoin server retains the technical authority to falsely trigger a firmcoin to think its loaded?

Good point. But it doesn't work like that.
Anyone can load a certificate to the firmcoin tho prove the coins are valid, and the firmcoin will gladly accept it.
The coin can have (currently) up to 8 user provided certificates.
So if you don't trust the manufacturer, you can reject a coin that has only the certification of the manufacturer.
Maybe The Bitcoin Foundation in the future can be generating its own certificates to put into the firmcoins.

Anyway, why we are providing the method 2, that is exactly what you say in your post. The firmcoin tells you which method was used to load the coins.

edit: I guess you're concerned that proper validation is too expensive for the coin,

Yes, it requires much computation, but the nice fact is that it can be done incrementally with little memory.