I guess the interesting thing about CoinSwap is that the participants do keep some records about what they did.
Yes, it's a major flaw of the idea and I'd be very interested to hear if anyone can figure out how to solve it. Hah. I don't _generally_ consider that a flaw. Selectable audibility is useful, so long as its the participants that control it. What is a flaw here is that Carol can tell you about Alice. In CJ, even a cryptographically blinded one, if setup right, you could also keep logs that enable you to prove to others how you transacted... but no one but you has that power. Doing so enables things like transparent business records— but ones which are only transparent to your investors, not your competition. (bolded by me) Proof-of-your-payment is very important, proof-of-someone-elses payment, on the other hand isn't something we want to make possible. Note how for the proof-of-payment case, the CoinSwap should be designed such that the escrow transactions are released not with signatures, but by giving the other party the relevant private keys. This lets that other party re-use those keys if needed later to fully prove they made the payment. The alternative, SIGHASH_NONE|ANYONECANPAY is also worse because it's not a standard way to sign a transaction input, and thus leaks more information. |
|
|
|
I guess the interesting thing about CoinSwap is that the participants do keep some records about what they did.
Yes, it's a major flaw of the idea and I'd be very interested to hear if anyone can figure out how to solve it. |
|
|
|
Very interesting. +1 for the diagram.
Would it still make sense if say, 50% of TXs were done using the elegant CoinJoin trick?
Absolutely, in fact CoinSwap itself can be used with CoinJoin for the transactions going into and out of the swap. Basically, a really good implementation would be if we had a P2P messaging layer to arrange for both CoinJoin and CoinSwap transactions. CoinJoin can be done in such a way that every transaction can use it, with no performance issues and a small cost savings, so using it for every transaction makes sense. CoinSwap can be used on demand for a small increase in transaction cost, and the requirement to wait for a confirmation or two before the transaction can go ahead. Good wallet software would handle the detail in the background, and counter-parties for your CoinSwap transactions can be picked randomly from whomever is available. (remember that you don't need dedicated "Carol"'s, if you want to send coins to Bob, you can do it by having Carol send them, or acting as Carol yourself and using Alice's coins to pay Bob) |
|
|
|
Petertodd would probably recommend bonding the cards in some (or multiple ways).
One way would be to make every card contain a shared bitcoin private key (same key in all cards) for some large amount of Bitcoin, visible sitting in the chain. The card could prove that it contains the key by being willing to do a bitcoin-signmessage for the key.
If someone can compromise your tamper resistance, they can obtain the coin and in doing so would alert everyone that the tamper-resistance has been compromised at least once.
Yup. There are more sophisticated ways of doing bonding, but I think for OtherCoin just doing the above is the way to go for v1.0 if you're pretty confident in the hardware. Just be clear to market this stuff for low-value, low-security-required applications initially and go slow with your expectations. Regarding trusted hardware in general, people have this mistaken idea that the idea is fundamentally flawed because the secrets will always be possible to exploit. What they don't realize is that 60 years ago you would have made the exact same argument about cryptography: "This encryption business will never work because mathematics will always be broken eventually." In the case of trusted hardware we're still not there, but it certainly in theoretically possible to build hardware systems that impossible to extract secrets from, simply because at some point you've built a circuit whose physical dimensions are so small that the only way to probe it is with the physical structures already built into it. I work in analog electronics myself, and there's lots of situations where its physically impossible to probe a circuit and determine what state it is in because physics simply does not allow you to do so. These limitations are every bit as real as the mathematical limitations that prevent someone from spending a Bitcoin they don't own, and future hardware designs that use them fully can and will be secure. |
|
|
|
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. |
|
|
|
|
Just installed this one one of my EC2 nodes.
No-wallet mode is going to be nice for that application.
|
|
|
|
but as number of these footprint increases (number of wallet used), it'll look more just like a big patch of transactions, rather than a patch of footprint in the middle of the desert no?
Nope. No matter how many wallets you make the coins all came from the same place. |
|
|
|
Then what about creating multiple wallets and send funds between it back and forth? As long as it's local, you are not sending the coins to anyone else but yourself.
Picture a huge expanse of desert sand. In the middle of the sand is thousands of footprints crossing in every direction. Surely no-one could ever identify these indistinct and commingled tracks! But our FBI investigator is smarter than that, and observes that while the middle of the sand is confusing, there is a clear border of untouched virgin sand, unmarred except for a single set of footprints entering, and a single set of footprints exiting... |
|
|
|
Ok, so as discussed on IRC, gmaxwell's clever idea doesn't work because OP_ADD/XOR/damn near anything is crippled. But I've got a better idea: Bob picks a secret value X and computes its hash H(X)=hx and tells that hash to Alice and Carol. So Alice pays into the following scriptPubKey with tx1: 2 <alice> <carol> 2 CHECKMULTISIG Next she signs a transaction, tx-alice-awol, spending that txout (remember tx mutability!) to the following scriptPubKey: HASH160 <hx> EQUALVERIFY <carol> CHECKSIG tx-alice-awol is not broadcast. Carol then pays Bob with a transaction output of the following form: HASH160 <hx> EQUALVERIFY 1 <carol> <bob> 2 CHECKMULTISIG To redeem that output, Bob is forced to reveal X, which allows Carol to use tx-alice-awol to get the funds payed to her by Alice. (we have to allow Carol to take the txout back, or Bob could just sit on it forever) Finally, once Alice sees that Bob has succesfully redeemed his txout, Alice also signs for her part of the tx1 output with SIGHASH_ANYONECANPAY|NONE, Carol saves this signature, which allows her to spend that txout later. |
|
|
|
No one should be doing serious work on the internet without a solid clock, and money is about as serious as serious gets.
Bitcoin can handle a clock that's off by roughly an hour off just fine. Clock accuracy just isn't a big deal. We were smart enough to avoid creating our own PKI in favor of the existing system that is good enough. Why aren't we smart enough to avoid creating our own clock synchronization system?
We didn't create a clock synchronization system, we created a peer averaging system. Think correctness vs. consensus. Also, if the PKI in the payment protocol is attacked, all that happens is some users lose their money. If there is a wide-spread NTP attack, especially affecting miners, the whole system can collapse. |
|
|
|
Regardless of how I wrote it, it's been in use for 2 years with only one address type. All testing and evaluation has been done with the single type that was in use. Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code."
The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money. Anything else would be reckless, no matter how the original code was written.
Well, what can I say, this is one of those things where adding P2SH v2.0 or whatever else comes next should be a lot less stressful if adding P2SH v1.0 is done well. Anyway, don't let me rush you. |
|
|
|
FWIW, these are also the same nodes which have been triggering the incorrect time warnings.
We should have fixed the time nonsense in bitcoin long ago. Despite the imperfections of NTP, there is no excuse for a p2p network (which runs on the same internet as NTP) to fudge the clock. If I have a good NTP lock, and I connect to a node with a different time, that node is wrong and should be kicked immediately. If I don't have a good NTP lock and I connect to a node which does, that node should kick me. I don't know that making whatever this is fix their clocks will cure anything, but it can't hurt, and we should have done it long ago. Emphasis on ifUnfortunately we can't just ship bitcoind out of the box with NTP support, because then whatever NTP servers we use - even if we use a whole bunch - suddenly become a central point of control of the whole Bitcoin network. This is made even worse by how NTP isn't authenticated. Maybe we could get away with abusing https and timestamping servers based on the logic they won't want to be proven to be lying, especially the latter, but ultimately we really just want users to set their damn clocks right. It's ugly and there's no good solution to the problem unfortunately. Satoshi should have picked something more like a six or twelve hour window, rather than two, but widening that window now is a hard-fork even to SPV clients. |
|
|
|
It's the same thing. A real bitcoind node isn't useless, so if a useless node claims to be a Satoshi node, we know it's not.
Right, but if we know it's useless, who cares what subver it claims? |
|
|
|
The simplicity is over-stated. The concept is simple and can be represented in 5 lines of code. But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address. These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.
The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins. Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.
For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts.
With all due respect, that your code was designed in such a way that is assumed one address type is something I would be a little embarrassed about myself - even in the early days it was easy to see how different types of addresses would simply have to be developed in the future if the scripting system was going to be of any use. But in the meantime, I wouldn't be embarrassed to take however long it takes to do it right! |
|
|
|
If they're determined to forge a fake subVer then it won't help much. If they're doing that because they're lazy or because they just modified a regular Satoshi codebase and forgot, then it might give them the incentive they need to announce themselves in a useful manner.
Right, so whack-a-mole, even in the best case. We're better off figuring out better ways of detecting useless peers and dropping them than wasting time coming up with case-specific fixes. |
|
|
|
We may have a smarter way to archive. We don't need to do it byte-by-byte. Use a single byte to denote common output scripts so the archive nodes may drop all those "OP_EQUALVERIFY OP_CHECKSIG " crap
That's already how sipa's UTXO database works. FWIW I used to think otherwise, but I agree with Mike for the most part these days as I'm 99% sure UTXO growth isn't a major problem. I'll publish something better soon, but in the meanwhile gmaxwell has a nice summary: https://bitcointalk.org/index.php?topic=314467.msg3371194#msg3371194Having said that, P2SH needs wider support all the same. It's embarrassing that something that should take about five lines of code isn't supported in so much wallet software. |
|
|
|
The other thing we could do is start to politely disconnect nodes that appear to be forging their subVer field. Unfortunately the lack of any kind of error message in the protocol means there's no way to send a message to the node before it's disconnected ....
Suggestions on how to do this that won't turn into a game of whack-a-mole? |
|
|
|
There was a gap in funding in late September, and then I went incommunicado for a few weeks, because of this:  Congrats! Sent you a donation for his or her college fund.  Now that we're back home and settled, I'm back to working on authentication trees. Thanks in large part to the generous donation of Armory Technologies, Inc. and a few others, and the recent rise in price, I have the ability to focus on this project for some more months.
Right now I am translating the Python code into a C++ libauthtree implementation, and working on a series of BIPs that describe the trie structure, various generic operations on it, and the specific application to txid indices, address indices, and merged mining. Invictus Innovations is helping with the BIP process due to their interested in using the structure for merged mining headers.
I will be consolidating the recent news into a blog post update soon, hopefully by the end of the week.
I should write up a similar document explaining TXO commitments. |
|
|
|
@jgarzik, due to provably unspendable outputs only taking 80 bytes, is the "official identity protocol" going to move away from announce/commit sacrifices? Should the sacrifice just be burned in a OP_RETURN HASH160(MPK) output until something better comes along (like the OP_VERIFY_LOCKTIME that retep mentioned)?
I can't speak for jgarzik, but I think this is the right approach. As pointed out above announce/commit can incentivize mining centralization, which is extremely bad. I think that downside outweighs the good that sending more fees to miners ever could do; miners already have pretty generous inflation subsidy for now. |
|
|
|
Peter's script sends the dust to miners - I suspect most people simply want to consolidate/defrag their wallet and keep the money. I don't think there's any program that does that currently.
What do you suggest such a script do? |
|
|
|
|
Show Posts
