|
I agree with your analysis; given the use-case is low-value payments, better to have a solid privacy guarantee and slightly weaker loss reistance than the other way around. After all, this thing could be useful for privacy too.
Reminds me: it'd be good to add some features to make it possible to to secure trades on a blockchain. Right now your OtherCoin.pdf whitepaper suggests two functions, generate key, and securely transfer key to another card. I think you actually need a third function that does bi-directional key transfer atomically.
Suppose Alice has 50LTC and Bob has 1BTC. They want to trade like for like. They can do this by first transferring the currency into an address that their respective OtherCoin card has control of and letting the transaction confirm. Next they tell their cards the transaction they want to make, Alice: "Give up secret key Alice_LTC in exchange for secret key Bob_BTC" and Bob: "Give up sec key Bob_BTC in exchange for Alice_LTC"
Now the two cards can communicate with each other securely. (being fully atomic and non-jam-proof will be tricky) When they're finished either party can repeat the process, or potentially just reveal the secret keys entirely so the coins can be spend normally. Interestingly the cards themselves don't have to have any concept of trust; all the cards care about was that they got a signed ACK from the other side. Whether or not that signature was from a trustworthy card can be left up to the user to evaluate.
Speaking of, you forgot to include "Reveal a secret key" in your list of basic operations. In fact, what you actually want to do is a bit more subtle than in your whitepaper: you should always be able to get your OtherCoin device to produce an encrypted and then signed message containing a given secret key. What key the message is encrypted to is irrelevant: under all circumstances once this message has been produced the OtherCoin device is guaranteed to securely delete the key from memory and never produce another such message. At the same time the device is also guaranteed to only accept a new secret key if the key is encrypted and signed by a trusted sender.
What's neat about this is it gives a one-sided upgrade path: new devices can still accept secret keys from old, but still trusted, device. For instance if the master secret keys are ever lost, you can create a new set and issue new devices that can still accept secret keys from the old devices, even if the old won't accept keys from the new.
|
|
|
|
Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f)
Didn't you explain it in the OP? If one uses SIGHASH_SINGLE without a corresponding output, a signature for 0000000000000000000000000000000000000000000000000000000000000001 is valid Yup, exactly - come to think of it the example would have been better done by spending three outputs, with two valid-yet-the-same-signature ones. Thanks, fixed. |
|
|
|
Compare the scriptSigs against the one in this transaction: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f
I can't read C++, but it seems it works like this: - For the first input, it is an invalid SIGHHASH_SINGLE signature, so the overall script is valid (with OP_NOT)
- For the second input, for the same reason as 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f, it is valid
[/list] Ok, but then if the signature is valid on the second input, how can the exact same signature be valid for a totally different transaction spending normal inputs? (the second one I provided, 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f) |
|
|
|
|
Also, here's another fun puzzle: 61d47409a240a4b67ce75ec4dffa30e1863485f8fe64a6334410347692f9e60e
How is the byte string 000080 not true, yet any other non-zero bytestring does evaluate as true?
|
|
|
|
|
For 1BTC I will tell you how to make these super quick blockchains.
I've also got a lovely piece of engineering for sale that crosses a local river.
|
|
|
|
Yes, I was wrong.
For the second input, the serialized script is simply OP_CHECKSIG. So one can use ANY public key with a correct signature to redeem it, right? (normally, the public key is part of the serialized script)
For the first one, the serialized script is OP_CHECKSIG OP_NOT. So one can use any public key with a WRONG signature to redeem it.
I didn't check the validity of the signature but obviously they use the same signature and public key...... So there must be something wrong in my interpretation....
Compare the scriptSigs against the one in this transaction: 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f |
|
|
|
Here's a good test if you think you have a hope of re-implementing Bitcoin exactly: a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d
Tell me how that transaction got mined in detail.
The HASH160 of 0xac91 is 0x827fe37ec405346ad4e995323cea83559537b89e so it is valid? EDIT: The HASH160 of 0xac is 0x17be79cf51aa88feebb0a25e9d6a153ead585e59 So actually there is no CHECKSIG done here You need to learn how P2SH works: BIP16 |
|
|
|
|
Here's a good test if you think you have a hope of re-implementing Bitcoin exactly: a59012de71dafa1510fd57d339ff488d50da4808c9fd4c001d6de8874d8aa26d
Tell me how that transaction got mined in detail.
|
|
|
|
|
...and webbtc/coinbase is forked yet again on 0000000000000001e4241fd0b3469a713f41c5682605451c05d3033288fb2244
Probably tx df95ff9ac165abe7adb0091b5f1020c25203fd0c16c95b4c7fa6a4475428ef1f, although there's a bunch of other possibilities in there.
|
|
|
|
|
I see you now support sending to P2SH, great!
Looks like it's not working yet for Shared Coin, debug console says:
"Executing Stage 1" sharedcoin.min.js:1
17:25:52.367 "executeOffer failed Strange script output" sharedcoin.min.js:1
17:25:58.488 "Strange script output" wallet.min.js:1
17:26:00.496 "Recover Seed"
|
|
|
|
Yeah, I figured there are hairy problems about scripts depending on arbitrary other transactions. Maybe Satoshi gave up on making script really work because he didn't know if he could do it right. Best to get a solid foundation first.
Heck, having transactions depend on other transactions in a block is a potential scalability problem because it makes it non-trivial to process blocks and update the UTXO set in parallel, especially in a lossely coupled manner. (ie multiple co-operating nodes) |
|
|
|
|
Vitalik: Is that a true fee that goes to miners, or a sacrifice?
|
|
|
|
I can't speak for the Armory devs, but one nice thing about implementing stealth addresses in Armory is that it already has the machinery to scan the blockchain; you could easily use stealth at the highest privacy level where any stealth tx that's sent could be going to you. (zero-filtering)
It's something to consider about Armory in general: because it can work so easily with a local full-node you always have excellent privacy with regard to the contents of your wallet. All the queries are local, so info on what coins are in your wallet never leaves your machine. That's much better than SPV clients like Android Wallet where every peer you connect to learns statistical info narrowing down your addresses to within about one in 10,000 or so, or Electrum which currently just tells peers what addresses are in your wallet.
I'm very interested in this feature. It's just that it still sounds very theoretical at the moment. I'm also concerned about how much computation it will be to track the addresses ... ECDH calculations aren't cheap. I guess I'm still in a waiting mode, implementing other things while I wait for this to be ironed out (I don't have much to contribute to the discussion, though I have spent a lot of time thinking about how to get the same benefits without all the ECDH calcs). By my standards, stealth addresses are pretty concrete.  But yeah, part of why I was interested in working with someone was to nail down some of the implementation issues in a real-world client, speed being one of them. My basic idea was to have a bandwidth/speed/privacy tradeoff, and there's some interesting ideas being discussed right now on what's the best way to do that. One key implementation question is can the Armory codebase handle addresses where to pay them you have to make a transaction with not just one, but two specific txouts? Peter: Btw, I'm working on P2SH support right now. You will be able to test it on 0.91-dev in the next couple days. In fact, it seems to be working right now, on the p2shout branch -- you can try it right now, though I wouldn't do anything other than testnet.
As part of the update, I modified the PyTxDistProposal::createFromTxOutSelection() method to take any arbitrary list of script-value pairs, instead of just hash160 values. Right now, it will error out if you supply it something other than an P2PubKeyHash or P2SH, but that could be modified locally to create a tx with any arbitrary output scripts. As long as all the inputs are standard UTXOs, you can create such a tx and sign it no problem (have fun getting it mined, though).
Excellent! Sorry for the late reply, but I finally got a chance to try that branch out. Looks fine to me, although I see the odd IndexError on the console, not sure if it's related:
(ERROR) Traceback (most recent call last):
File "/home/pete/src/bitcoin/BitcoinArmory/qtdialogs.py", line 9301, in showContextMenuTx
idx = self.addrBookTxView.selectedIndexes()[0]
IndexError: list index out of range
|
|
|
|
Have you seen Bitrated yet? I'd strongly advise you to contact them and see what it'd take to add support for oracle transactions to their escrow service. You could almost even use it as-is right now, except that the system only (currently) lets you set a single pubkey for the escrow agent. |
|
|
|
Tor does not fundamentally break by having who runs what nodes be publicly known - that's exactly how Tor already works.
I think you're misreading what was said. Tor breaks if you pick three relays you think are not collaborating against you, but they actually are. Obviously if the Tor network is flooded with nodes that look superficially unrelated but are all run by an adversay, the chances of being deanonymized go up a lot. I did not say you can't tell Tor nodes apart, so I'm not "propagating falsehoods". I said you can't know if they're really run by independent entities or by the same guy/people. Ah, yeah, my mistake, I misread that. Anyone who wants to run Tor nodes can get a passport or use their existing one, it's not like there's a "no Tor" rule enforced by any countries passport office.
GCHQ might well be able to fake a large number of British passports, or heck, just use those of their employees. Perhaps they've even been able to hack a foreign country or two's passport agencies - who knows. But you can play geopolitics by having the ZKPOP reveal the issuing country and then picking relays run by citizens of countries that hate each other. That raises the stakes a lot - if GCHQ is forging a foreign countries passports that can, if discovered, turn into a major diplomatic disaster that isn't worth it.
In the current world all they have to do is rent a lot of servers around the world via front companies, hardly a big deal, and then run modified Tor nodes that log circuit activity. It can't get any easier than that.
It's just simple numbers - there's ~3,000 Tor nodes out there, and actually quite a bit less than that in terms of bandwidth product. If you don't create something honest people actually use, on a wide scale, what you've created is something that dishonest people use, on a wider scale. Remember that passports are held by large numbers of people, the GCHQ isn't going to have a hard time finding government employee with all kinds of passports, Russian, Chinese etc. even without faking them. (my former ~50 person company had individuals with those passports, and Iran, India and Pakistan among others) And if they do decide to hack them you've got a handy anonymous ZK proof scheme to cover up the fact you've done that. |
|
|
|
2) Flooding networks with peers that look unrelated but actually aren't. After giving it some more thought, I am starting to think that this can't be solved. The problem with Tor is that you can't tell nodes apart. This, I believe, is a fundamental property of Tor as it intends to hide any network information. There is simply no way of knowing whether two or more nodes are on the same computer and controlled by a single person or group. Mike is propagating falsehoods. Here's a list of all Tor nodes: http://torstatus.blutmagie.de/ The organizations running many of those nodes make a point of advertising who they are and the fingerprints of the exit nodes they run: https://www.torservers.net/exits.html That also applies to relay nodes: http://www.enn.lu/status/relayTor is a technology, but it itself is just a tool; the reason why Tor can be used relatively safely is actually because of human social protections, not just cryptography. Infiltrating Tor is harder than it looks because you have to infiltrate large numbers of real-world organizations comprised of actual people - just the kind of thing that leads to rather undesirable leaks. It's also rather similar to how I've argued for some time now that the Electrum SPV clients are probably more secure and private because they rely on a small number of Electrum servers run by relatively accountable people rather than a large number of completely Bitcoin nodes run by parties unknown. |
|
|
|
2) Flooding networks with peers that look unrelated but actually aren't. Tor has the same problem, so I'm interested in solutions that generalise to all P2P networks. For these proofs of propagation etc are irrelevant. For Bitcoin it might be possible in every case to come up with fancy tricks based on proof of work, though remember someone has to actually write the code for all of these ideas! But I don't see how to avoid the issue with Tor. There just isn't any reasonable way that the Tor directory operators can know if nodes are related today, and if they are, Tor fundamentally breaks. Given that GCHQ has been tasked with breaking Tor (they're thinking of the children you see), advanced sybil attacks on it seem more likely than not in the near future.
It's easy to know if some Tor nodes are related and who runs them: there's a large number of high-bandwidth donation-based nodes run by various charitable organizations, e.g. torservers.net, and those nodes are well known. Tor does not fundamentally break by having who runs what nodes be publicly known - that's exactly how Tor already works. The other interesting thing is that because tor is a semi-centralized system proof-of-bandwidth and proof-of-low-latency is practical - the central organization is trusted and can make the measurements - and that makes for a good lower-bounds on the financial resources expended to run those Tor nodes and the geographical decentralization of them. Basically it's a better version of proof-of-sacrifice, better because the "sacrifice" is inherently the thing you're suppose to be providing. You're criticisms do apply to the I2P network though, a common criticism of it verses Tor. Meanwhile if the GCHQ is your adversary, why are you making their job easier by giving them a huge advantage - they have access to tens of thousands of real and faked passports - that the honest defenders don't have? |
|
|
|
Agree with you about your second point. Any thoughts on a 'proof-of-connectivity' for nodes, or am I just re-thinking the 'proof-of-propagation' issue?
I think you're extending it really, and you're probably not extending it in a way that really works. A good question to ask yourself is "How could I attack this with a bunch of fake proofs?" As to your first point - some pubs take thousands in alcohol sales in a single night. If you could MITM them, laptop in a bag hidden in the middle of the busy room, they'd be in big trouble. This is where I feel zero-conf guarantees will be needed.
Nah, a pub is a pretty good example of why zero-conf doesn't matter all that much: If someone rips you off, you've got a pretty good chance of finding out in a few minutes. Ask the bartender which patron paid for it and have your bouncer go have a chat with them. Even with the busiest clubs this works pretty well - they've got security cameras everywhere to track down that person. |
|
|
|
So if one has dual citizenship and can consequently have more that one passport one can run more than one node.
I have two passports, my kids have 3 passports each, so I can run 8 nodes on a wifi network attack and you'd think you were connected to the network, so this passport concept is flawed from the start. Not to mention the fact that if you go to any factory around here you can guarantee the manager has like 100 Cambodian passports in a stack (so the employees can't run away). There are probably some factories will access to literally thousands of passports. Not to mention if I traveled to somewhere like Nigeria with a pocket full of cash...how many passports could I scan in 10 minutes? It's one of those ideas that rather than keeping the bad guys out, discourages the good guys from contributing - "I'm not trusting this random program with my passport. How do I know this crypto moon-magic actually works?" - while giving a way for the bad guys to easily use their resources to buy fake legitimacy. Much better to design systems where the bad guys can't do any harm in the first place. |
|
|
|
|
Show Posts
