|
Yeah.
If you assume a trust in the authority that made the card, then you can as well ask the card itself how many coins are covered by a private key it gives you.
it should give you the info signed with its private key, that is signed with the authority's private key - so it's all about the trust to the authority and you can move coins offline.
It's a brilliant idea, @drazvan
|
|
|
|
But how do you see the accounting part?
If the only thing the card can transfer is a Bitcoin private key, then it should be somehow known how many coins are there, behind this private key..
How do you see this?
That's the beauty of it... it doesn't ... the card never knows anything about Bitcoins or balances or anything like that. That's the job of the wallet running on your smartphone or whatever you have the OtherCoin card inserted into. The wallet acts like any other "watching" wallet, it can monitor balances, etc. It's only when it tries to pay from that address that it needs the private key - and it can either ask the card for it (in which case it's removed from secure storage and the wallet just uses it on the Bitcoin network) or it can ask the card to securely send it to the recipient's card (in which case it is encrypted with the recipient's RSA key and given to the wallet in encrypted form to be sent to the other end). The card cannot sign Bitcoin transactions and only acts as a very "stubborn" Bitcoin key generator - you can ask it to generate a key, it will give you the corresponding public key but keep the private key secure, allowing you to do anything other than transfer the funds away. It's the wallet's job to monitor the blockchain, establish balances and communicate to the recipient (since the card has communication capabilities other than its physical interface to the smartphone using the microSD slot). I am thinking whether it would be possible to use such a card for offline transactions. I mean, if you arm it with private keys that have access to some predefined amount of coins (e.g. 0.1 BTC each) - then you could essentially trade such a credits offline. |
|
|
|
|
But how do you see the accounting part?
If the only thing the card can transfer is a Bitcoin private key, then it should be somehow known how many coins are there, behind this private key..
How do you see this?
|
|
|
|
|
Did you guys also notice that there is an entire subnet 129.132.230.0/24 doing quite a similar stuff...?
|
|
|
|
Cool - thanks for explaining. So REVEAL removes the Bitcoin from the card's balance storage, though keeps it in the card's NVM, encrypted with the recipient's RSA. The recipient can request this RSA encrypted key as many times, as it wants - until it gives the REMOVE command, which essentially frees the memory in card A. Yeah, I like this idea. And sorry for not reading through carefully, at the first time, asking these questions instead.  But it's all clear now and I like it - I think it can work. |
|
|
|
Piotr_n, there is no private key that all the cards share. They all share the public key of the issuer in order to be able to verify other cards and ensure that the Bitcoin private keys are only transferred to cards issued with the same restrictions and running the same software. Each card comes with its own "device key" (I think this is called an "endorsement key" in TPM world - see http://en.wikipedia.org/wiki/Trusted_Platform_Module ). The root private key (used to sign the endorsement keys) is definitely not present on any of the cards. Oh, OK. So each card would have a unique private key and its corresponding public key, that would be signed by the issuing authority? Now it starts making much more sense. This can indeed work - as long as the private key used to sign the public keys of the cards they manufacture does not leak out of the authority. Which is again: usually only a matter of time and money... But OK - let's assume that it won't leak out. In such case I have another concern. From what I understand moving bitcoins from one card to another means sending the key from card A to B - storing it in card B, while destroying it in card A. But is there some reliable method to avoid destroying the key in A too soon, or too late? If you destroy it too soon, the coins will get lost - if you do it too late, you might end up with the same key being owned by two cards. |
|
|
|
I've yet to hear about criminals decapping chips en-masse and exploiting the system that way, despite massive incentive to do so. I would not call the guy a criminal, but... http://www.youtube.com/watch?v=Qk73ye2_g4oFor the application we are talking about, all it takes to extract the authority's private key is to successfully hack one card. You might destroy hundreds of thousands of them, on the way there, but all you need is the master key that is shared among all of them. So one is enough and you can make millions of fake ones ever since that moment. |
|
|
|
It's a nice idea, but as you say yourself "The only trusted authority is the issuer of the OtherCoin card". So first of all you need to trust an authority. Second, you need to have some kind of making sure that the card is not just pretending to be issued by an authority - this I guess you can do by putting the authority's private key inside the card and telling it to sign messages with it. But the third problem is (and I had worked with smart cards for awhile) that basically every smart card can be hacked - it is only a matter of time and money. So eventually someone will manage to get the authority's private key out of it and then will be able to make his own, fake cards. And on top of that, there is always tha ever lasting: how can you even trust an authority? But the idea is appealing and probably worth exploring. |
|
|
|
p.s.
Will you pull my gitian sigs if I make some?
I can't speak for Warren, but the general idea with gitian sigs is the more the better. We want lots of people from the community to use gitian - pretty much no matter who you are a gitian sig from you will increase someone's confidence in the build. ok - I'm on it.. all I can tell you ATM, before going to bed, is that my win32 sigs are different https://github.com/piotrnar/gitian.sigs.omg/tree/master/0.8.5-OMG1-win32/piotrnarthough I took the HEAD - might that be the problem? I would not think so, since its the same commit id as the tag: 5b474dacd8ae0d32f8c76dead7b7e9905d868ec3 I rebuilt all deps from scratch and the resulting .exe's came out identical to my previous gitian sigs. I'm asking others to join gitian build tests to figure out what is going on here. Now I see what I did wrong. I did not set the VERSION var properly (0.8.5 instead of 0.8.5-OMG1) and fetched wrong sources. Shouldn't be doing it so late and announcing such a message just before going to sleep - my apologies. I'm redoing it right now. |
|
|
|
If you feel strongly enough that the threat is so great that we need to take action now, feel free to do so. I think you miss the point, that I don't consider you as my ally in this war. I can take the action in changing the protocol, but nobody is going to use my code, so it won't work. The only reasonable action I could take facing this threat is converting all my bitcoin savings to another asset. Which I partially did, but I would still like to help bitcoin in resisting a potential NSA backdoor, or whoever else could have put such a thing in there. There was this topic on the forum where we were trying to figure out how they chose the G point for the Kobus curve. And exactly as I had predicted: they did not tell us - it's just a one big mastery how they picked the "random" point. And that is why I trust more in RSA/DSA - because there is no a mysterious "random" point. |
|
|
|
The faux-urgency of speculative ideas is not helpful. Rushing in changes "ASAP" is a danger to the network with probabilities much higher that spontaneous EC weakness. I've proposed having an alternative non-hidden-subgroup-problem signature algorithm at least as far back as early 2011, and written out some more concrete descriptions, though I'm a bit disinclined to post an implementation where some crap altcoin will just rip it off and claim an advantage over Bitcoin. But, regardless, it's not something we can or should rush into. You are so right. But if you have been waiting for your idea to go through since 2011, how much longer do you plan to wait, if you don't mind me asking, before concluding that it's already too long? You obviously understand the seriousness of a potential problem and all the cons of rushing the solution - that's the approach we need. Therefore you should be able to judge a good balance between the two things. And where do you see the balance being finally implemented? I hope not in 2020 |
|
|
|
p.s.
Will you pull my gitian sigs if I make some?
I can't speak for Warren, but the general idea with gitian sigs is the more the better. We want lots of people from the community to use gitian - pretty much no matter who you are a gitian sig from you will increase someone's confidence in the build. ok - I'm on it.. |
|
|
|
|
You're right @Cryddit - it's a good solution to broadcast your own txs slowly, like each new second you send it to another peer... there is no rush with it anyway.
But I think they might also be spying for mining nodes - and a mining node wants to propagate new blocks as quickly as possible.
So that's a tough problem to solve.
What I do in my client now, I never broadcast locally created txs to nodes that have not sent me any inv.
But when they find out what I do, its easy to circumvent - all they need to do is send me an inv once for awhile.
|
|
|
|
This is great - will it be merged into Bitcoin 0.9 somehow?
I think wtogami just got tired waiting for 0.9 with all the crap and decided to take the development into his own hands, putting in the useful features. And that's exactly what this community needs. @wtogami, make your own 0.9 and then 1.0 - people need it. Don't look behind. p.s. Will you pull my gitian sigs if I make some? |
|
|
|
But it will still cause a hard fork, if you try to spend it with a wrong signature, while having some old mining nodes in the network, won't it?
Thats part of the definition of a soft fork. If there is a super-majority of miners enforcing the rule the majority will pull over the old mining nodes, they'll lose some blocks here and there but the consensus will be preserved. OK, thanks for explaining. But a super-majority is a relative term. What we are talking about here is in fact any majority, meaning: more than 50%. If we want to have a super-majority around this, in a close future, you guys better put these new opcodes into the reference client ASAP, and I will follow you adding them to mine, because that would be one of a few changes in the chain protocol that I am supporting today with my all hands. I am sure the members of the core dev team also own lots of bitcoins and I hope they don't all have the "sudden catastrophic break in ECDSA is pretty much unimaginable" approach. If not for me, do it for your own interest. Please. |
|
|
|
Can you?
Maybe I miss something, but there is no opcode to do RSA or DSA verify - so how can you add it without a hard fork?
You can. You simply add them. You write a transaction which looks like an {anyone can spend} to old nodes, but looks like {$XYZ required to spend}. Old nodes are happy, and the transactions are safe to use as soon as a supermajority of miners imposes the new rule. But it will still cause a hard fork, if you try to spend it with a wrong signature, while having some old mining nodes in the network, won't it? |
|
|
|
No. You can change pretty much anything in the protocol with soft-fork. Adding new DSAs and Hash algorithms are certainly soft-forks. Imagine to have a script protected by 3 different DSAs and 5 Hash algorithms.....
Can you? Maybe I miss something, but there is no opcode to do RSA or DSA verify - so how can you add it without a hard fork? |
|
|
|
This solution has flaws, but is better than nothing.
The concerns about a possible weaknesses in ECDSA are serious and not addressing them ASAP is irresponsible, to say the least.
Protection against a potential weakness in ECDSA has been included since day 1. Don't reuse keys. It doesn't help, if someone can crack the key before your tx gets confirmed and has a better access to miners. Use your imagination, mr bitcoin elite. |
|
|
|
|
Show Posts
