The Ka-ching Project

[Norway]

Thanks @Tom Zander . I'm not letting you off the hook easy either, he he. I have to do the quote-answer-thing here.

> We have to compare this to current phone wallets like Bitcoin.com's wallet and Trezor.

I hope you can challange the status-quo more than that.

You set out to create a 100% hardware wallet and the first thing you do is remove most of the benefits of this by making an internet connected device create the private keys.

I'm not trying to make a Trezor! I'm trying to make something new. The status-quo has Trezors and phones. This is better in many ways. A 100% hardware wallet (what does that even mean) does not mean 100% security. That is not the goal.

By using Trezor and Bitcoin.com's wallet as examples, I try to explain the tradeoffs. I'm very clear about the different attack scenarios. Phone screenshots that is relevant to all phones asking you to write down a seed. And how entropy/randomness can be done better.

You have an awesome idea that has practically zero user interface (learning curve extremely flat) and you then go and make seeds, backups, phone apps and lots of complex stuff.

Thank you. The seeds, backups, phone apps is exactly what the user friendly Bitcoin.com wallet does today. Regarding the "lots of complex stuff", I have no idea what you talk about. And it does work without phone pairing. I listed the benefits of phone pairing.

I'm arguing for no backups and a once in a lifetime re-pin (which addresses the trusting the hardware-makers issue). Are you sure that my suggestions are those of an overexcited expert? I don't let you off the hook that easy, the proposals I made will have the effect to make the user interface dead-easy. Saying I'm an bitcoin-expert is a weird defence.

So you have to have a "factory pin" that can be exploited by a factory worker and kept like the "PUK" kode for phones (Ihate that).

So you can make a new one, and use it the rest of your life? I guess this "pin" has to contain the same entropy/combinations that a 12 word seed has.

Where this comparison falls down is that I can ask you to send me a payment and instead of taking your money I overwrite your private key. Your design makes a normal action and a destructive action have 100% the same user interface and priviledge levels (a botton press). Thats going to cause people pain.

Aha! This is a good question! The "normal" action can be just as destructive to the owner as the "destructive" action is. If a malicious actor or a bad written program takes all your money or erase your key, it will have the same outcome for the owner.

Again, if you press the activation button near an NFC antenna, you always risk to lose all your money.

That's the basic premise here.
[doublepost=1523998928,1523998217][/doublepost]This is not an attempt to create the most secure hardware wallet. It will be less secure than Trezor. The "vault" will be more secure than Bitcoin.com's wallet. The Ka-ching device on it's own, will be less secure than both Trezor and Bitcoin.com's wallet.

But it will be insane useful. And in many ways, more secure and better than a contactless VISA card.
[doublepost=1523999231][/doublepost]@Tom Zander
I'd like to hear more of your PIN solution. But it's a hard sell to demand a paper following the device from the factory. (#NOPUK)

 

[Norway]

To follow up: Your Ka-ching should be a cheap, disposable unit. The seed backup is what you keep for life. And you can create as many vaults and pair as many Ka-ching devices as you want.

Everything can be recovered from the seed.

CryptoSteel is still relevant and cool. I'm not trying to solve that problem better than Wojciech

 

[Tom Zander]

Thank you. The seeds, backups, phone apps is exactly what the user friendly Bitcoin.com wallet does today. Regarding the "lots of complex stuff", I have no idea what you talk about.

I made a suggestion, it is much easier because it doesn't have a phone, it doesn't have a seed and it doesn't have a backup.

Why did you add all of those features?
The only effect I see is that setup and usage become much more complex.

So you have to have a "factory pin" that can be exploited by a factory worker and kept like the "PUK" kode for phones

Ehm, no.
Similar to how a miner getting a miners reward doesn't make him able to exploit anyone else owning (part of) the coin after he sold them.

So you can make a new one, and use it the rest of your life? I guess this "pin" has to contain the same entropy/combinations that a 12 word seed has.

No. It would be very much shorter. Its main purpose is to block everyone, including the factory worker, out of your ring. If you never intend to re-sell the ring, you don't even need to remember it.
[doublepost=1524059479,1524058609][/doublepost]

The status-quo has Trezors and phones. This is better in many ways. A 100% hardware wallet (what does that even mean)

A trezor is not a hardware wallet, it is a second compontent to a computer based wallet (phone or laptop etc).
The main advantage is that the private keys never touch an internet connected device.

Phone wallets are the simplest, they can be completely different because they connect to the Bitcoin network and for that reason they have plenty of issues.

A "100% hardware wallet" is one that doesn't require the owner to use a second component like a computer to do payments. 100% of your wallet is in that NFC bearing hardware.
Topping up requires you to send the actual transactions, over NFC, to the ring because it doesn't have any other way to get that data (the ring obviously trusts the person topping it up to send the transaction to the network as well).
Payments require the ring to send the transaction to the payee/merchant so they can validate and forward.

The benefits fall into two catagories;

1. There is never any internet facing device that needs to know the private keys. Safety goes up.
2. The usability is better than all the other solutions because you remove unneeded concepts.

 

[Richard3]

The main difference here is that Flowee Cashier requires a Flowee the Hub running, which has the requirements of a full node. As such this is for the larger companies and larger volumes as the cost is higher but the risk (the trust in external parties) is practically zero.

MiniPOS seems to require the "MiniPOS server" which I assumed is either a full or SPV node.

6. Event II: New private key
The device receives a new private key.
The device overwrites the old private key with the new.

As a rule of thumb in crypto it's not a good idea to transmit a private key or have it in multiple places. When the funds disappear, you don't know if the phone or the device was compromised.

I'd propose a 1-of-2 multisig, then either the device or phone can spend the money and it's clear which one did.

The device should generate it's own private key and never transmit it.

I think this is too simplistic since it can loose your funds still locked in that private key.

Ideally you have two "secrets" on the device. One is the private key and one is a device-specific secret. Like a pin, just not that trivial to hack.
When you pair with the device you need to read the manual and copy the factory-default PIN into your phone app and set it to a new one that from then on is the only one that can replace the private keys.

If you combine my suggestion above with BIP32 HDWs, pairing is just a case of confidentially exchanging XPUBs. This also eliminates address re-use as now you can generate 1-of-2 multisig change addresses.

If you lose or destroy either the device or the phone, funds can be recovered from the remaining device.

If you want to keep it super-simple and have no pairing then you could forget multisig and HDW and just a have a QR code on the card (or packaging if it's a wearable) for top-up and refunds, but you sacrifice transaction privacy through re-use of the change / top-up address.

Personally I would want a companion app / wallet anyway, and transaction privacy, so I don't think pairing is a burdon.

 

[Richard3]

PS: as for authorising a re-pair or re-seed, I wonder if it's a valid argument that an empty wallet and a depressed button are sufficient?

 

[Richard3]

I don't think you should pair. And you should not make the phone create your private key. Because both of those undermine the benefits of it being an off-the-internet hardware wallet.

If it has no pairing and is "off-the-internet" then it has no way of knowing its own balance, so it can't construct transactions because it does not know how much to spend to the change address.

Correct me if I'm wrong.

Also means my 1-of-2 multisig will result in a double spend attempt if you ever tried to use a card after "recovering" its funds through the app. I don't think this is a problem.

 

[Tom Zander]

> If it has no pairing and is "off-the-internet" then it has no way of knowing its own balance

The beauty of the proposed system is indeed that it doesn't use an internet connection. It can know its own balance by the person funding the ring giving that funding-transaction to the ring over the NFC. That avoids you needing to ask a 3rd party on the internet.

The current way of thinking about wallets is very much wrong for this situation and we need to re-view various assumptions people made, but in the end I am positive that the usability gains are more than worth it.

 

[Tom Zander]

To summarize and clarify my ideas, I wrote a yours.org post.

https://www.yours.org/content/everything-you-know-about--bitcoin--wallets-is-wrong-f9dd2dc4a7f7

I hope this is useful for the kaching project!

 

[Richard3]

To summarize and clarify my ideas, I wrote a yours.org post.

That post does a good job of summarising the Ka-ching idea and other ideas on this thread. I hope we're not the ones you describe as thinking about it "very much wrong". The thinking on this thread aligns to what you describe in your post under "Simple way forward".

It can know its own balance by the person funding the ring giving that funding-transaction to the ring over the NFC. That avoids you needing to ask a 3rd party on the internet.

A non-internet connected wallet was the whole aim of Ka-ching from the start. What we're doing on this thread is trying to find the best protocol between the device and its companion app. The companion app is for balance checks, transaction history and top-ups, it is not required for spending.

What you call "the person funding the ring giving that funding-transaction to the ring" is what I call top-up and we need a specification or protocol for it. One option is a special NDEF message to prompt the device to generate a BIP70 PaymentRequest with zero-value (which has special meaning, see spec) to which the companion app would respond with a BIP70 Payment including amount. Only when the app gets a PaymentAck from the device would it relay the transaction to the network, to avoid the device accidentally spending an unknown top-up as a giant fee. This BIP70 reversal might also work for refunds.

For spending, I agree BIP70 is sufficient (protobuffs over NDEF) and does not require the device to be connected to the internet or a 3rd party (or the companion app).

For balance checking, I think the companion app can query the chain based on the XPUB. So we are using BIP32 and need a protocol for exchanging the XPUB. Hence the need for what I call pairing. Along with balance checking, BIP32 gives us dynamic change addresses so we can avoid address re-use. Pairing would have other benefits too, such as allowing the user to set a maximum payment value.

@Tom Zander , I think your objections to pairing might be based on an interpretation similar to bluetooth pairing, where the device and phone establish and maintain a connection. That is definitely not what we are talking about, but if it's ambiguous I'm happy to give it another name such as syncing. To be clear, no-one was suggesting the phone / companion app needs to be present for spending.

 

[Tom Zander]

Sounds good, @Richard3.

The only thing I really objected to was the idea to generate a private key on a 'paired' device. The only reason I can see for this is because of this usecase (copied from a chat elsewhere)

I have $60 left on the kaching ring. I'm not buying from any PoS retailer now
but i need to send $30 to bitpay for something else, and being an American I have no other savings ready to use.

To people that are experts in Bitcoin you might conclude the following;

if my kaching doesn't share with phone, then i need to recover the seed on electron-cash or bitcoin.com and send to bitpay there

Notice the high level of technical terms in that sentence. This is expert stuff, people.

What about instead you treat the system much simpler as one device = one wallet. So in this usecase you have any NFC smart device create a payment request and you pay yourself (but your phone-wallet) with it so 10 seconds later you can pay bitpay with the received funds.

This means that suddenly you drop backups, you drop private keys, seeds and all sorts of techno-speak and the users will love you for it.

 

[Richard3]

Ok I think we are all on the same page now.

 

[Richard3]

A couple other considerations:

1. An extra reason for regular syncing with a companion app is to obtain the BIP70 "memo" data for enriching the transaction history on the companion app.

2. If the merchant were to try and refund money to the address it came from this would result in a loss of funds as they would be added to transaction fee when the next transaction was generated. BIP70 solves this by specifying a "refund_to" address, so it would be important to make use of that. Generated by the device but using the XPUB from the companion app / wallet.

 

[Tom Zander]

If the merchant were to try and refund money to the address it came from this would result in a loss of funds as they would be added to transaction fee when the next transaction was generated.

Stop thinking like this is a bank-account, think like this is a wallet with cash. Change the mindset and suddenly the solution is much simpler.

If you pay in a store with a $20 bill, your refund will be in person and using a similar $20 bill.

If you pay with your ring in a store and for some reason you need to do a refund, all you need in your point-of-sale application is a refund operation to the address that your ring provides the merchant with. Exactly the same as with cash. Bitcooin Cash is Cash.

This can be the same address stuff came from (which is legally required due to AML laws in many countries), but in this case the merchant uploads the transaction to the ring again, solving the problem you saw.

ps. you are wrong about the money being used as fee for a followup tx. That assumes bitcoin addresses are like bank-accounts and thats not how they work.

 

[Richard3]

ps. you are wrong about the money being used as fee for a followup tx. That assumes bitcoin addresses are like bank-accounts and thats not how they work.

Ok, got it. As inputs are transactions not addresses. That definitely makes things easier.