My suggestion: 1. Alice and Bob each lock up 3x the amount of bet using special insurance transaction: https://bitcointalk.org/index.php?topic=273539.02. Alice shows SHA256(X) to Bob. 3. Bob shows SHA256(Y) to Alice. 4. Then they share X and Y. If first bit of SHA256(X + Y) is 1, Alice wins. Otherwise, Bob wins. 5. Loser sends money to winner using normal transaction. 6. Repeat until they fed up. Then both unlock their deposit from step 1 and go home. This scheme is super-flexible because they can establish real trust with locked deposit and then play with any rules imaginable without being limited by Bitcoin or anything. |
|
|
|
|
There is no such tool because you won't iterate even a slightest portion of the keyspace in your lifetime. There is nothing to play with.
|
|
|
|
His white paper looks like it was made somebody who most likely went to grad school for computer science/cryptography.
So I think he works for a university.
Most mathematicians working for govt are coming from universities. The difference is that university folks are doing abstract research while NSA/CIA have very practical requests. In my opinion, Satoshi is employed by UK agency and does not want them to accuse him of any sort of espionage. I don't think he is a professor because he has many practical "educated guesses" while academics tend to prove everything more formally. And I doubt he is not employed and well-paid for his broad education. Government agencies like NSA are the first candidates to employ such people, pay them well and provide them with more or less comfortable conditions. (Private corporation would have to constantly meet production goals or risk losing money — it's a less comfortable place to be if you are not an owner.) |
|
|
|
Why does it have to be good or evil for it to be a government plan, can't it just be some gray area?
Difference is this: 1. Either it's some govt plan for whatever good/gray/bad reasons. 2. Or he/she is a single smart person working in NSA or another place that hire many smart cryptographers and hackers. He/she wants to change the world by releasing Bitcoin, but can be prosecuted for espionage by his/her own employee. Also, if people find out that Bitcoin is made by a someone in NSA, they might not trust it very much. |
|
|
|
|
There are generally 3 options that people speculate about: either Satoshi works for something like NSA (in US, UK or other country), or he/she is an academic, or some independent cypherpunk. Option about NSA is two-sided: either Bitcoin is an evil conspiracy against mankind, or it's a creation to save the world by someone in the knowledge within a well-funded government agency.
What's your speculation?
|
|
|
|
I think Satoshi was clearly not an expert cryptographer. His interest in ECC went as far as saying "this does digital signatures and takes less space than RSA". He may or may not have chosen secp256k1 because he saw mention of performance - if he did, then he didn't mention that when I explicitly asked him about it. Alternatively it could have been as simple as finding some example code somewhere on the net that happened to use that curve. He plugged it in, it worked, done.
As it happens, whatever the reason for selecting that curve, it's worked out pretty well for us all things considered. Of all the issues Bitcoin has, it turns out that ECC isn't one of them.
If he was not an expert cryptographer and secp256k1 was less used that r1, how did he end up with it? Random sample code would rather contain an "r" curve. I think he was quite serious about Bitcoin and took enough time to think through many complex aspects of it (and implement!) that many Bitcoin enthusiasts still don't get. Even if he wasn't an "expert" by your standard, I doubt he plugged in ECC implementation from a random sample code. I think he had reasons for almost every decision he was making. |
|
|
|
It's kinda interesting how "trust" could be misleading. Same people who advocated switching to a "more deployed random curve" just 2.5 years ago ( https://bitcointalk.org/index.php?topic=2699.0) now seriously distrust NIST parameters and prefer Koblitz curves for allowing less freedom in parameter choice. Even if Satoshi didn't know anything in particular about backdoors in random parameters, he might have chosen a less suspicious curve. |
|
|
|
|
Thanks for email address, I've sent you a message.
Offtopic: what do you mean by saying you are a "squatter"? Just for my education.
|
|
|
|
|
Amir, I have paid for two tickets to Unsystem conference in Vienna and received 0 feedback from you on what's happening about it. It would have been nice to receive a personal response from you, or all your work will be marked as highly suspicious in my eyes. Refund, for one thing, is welcome.
|
|
|
|
While writing documentation to CoreBitcoin (Objective-C implementation) I tend to explain some terms over and over again. To avoid repetition, I decided to come up with one more-or-less complete glossary of all technical Bitcoin terms from "difficulty" to "scriptPubSig". This glossary immediately answers a lot of questions that I myself had while learning how Bitcoin works. I hope it will greatly help newcomers to understand what people are talking about. Here's the latest version of the glossary: https://github.com/oleganza/CoreBitcoin/blob/master/GLOSSARY.mdFeel free to comment or even edit it on Github if you find mistakes. Thanks! |
|
|
|
|
UPDATE: The idea below won't work because, as gmaxwell pointed out, second transaction must reference first transaction by its hash. And this hash cannot be masked or omitted. But before computing this hash, we need to compute a signature of txB to put in the output script A. And we cannot compute the signature without having a valid hash to A in the first place. Vicious cycle.
So we want to lock some money for some time in the future without even a theoretical possibility to spend it earlier (e.g. by extracting the private keys by torture).
OP_CHECKSIG drops signatures from the script when computing a hash. This is mostly irrelevant today because script never contains signatures in the first place (as since 2010 input and output scripts are not concatenated). But the code is still here and we can use it:
1. Prepare any spending transaction A (single signature, multisig, complex script - whatever).
2. Prepare a valid transaction B with lockTime in 2033 which spends tx A somewhere further.
3. Sign tx B with some random key pair hash type SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. This will be "SigB" and the pubkey will be "PubKeyB".
4. Prepend the output script of transaction A with "SigB PubKeyB OP_CHECKSIGVERIFY".
5. Finally sign tx A and release it.
Now, you don't need to destroy any private keys: you have money provably locked to the transaction B. Even if you release private key that you used, it will not help: the transaction A already requires very specific transaction B to be used and tx B is time-locked.
Note that transaction B input script can be made empty completely, so you don't need to satisfy any extra conditions - just release tx B when it's lockTime is valid.
Why use SIGHASH_ANYONECANPAY and SIGHASH_SINGLE? It will allow you to add extra inputs to tx B if you will need to increase/decrease transaction fees. All other inputs and outputs except the first ones will be zeroed out, so you'll be free to adjust either of them in 20 years as you like.
Thugs will not be able to spend this money today even if they get all private keys from you. This should be enough to make kidnapping and extortion not worth it.
Now you can do something like this: lock 10% of your savings for 1 year, another 10% for 2 years and so on. You'll have steady access to your money if you happen to need it earlier.
Another idea:
Instead of OP_CHECKSIG and one signature you may have 1-of-2 MULTISIG with 2 signatures prepended. And you'll have not just one tx B, but txB1 and txB2. One of them (txB1) will move money further in the future, say, for 1 extra year. And another (txB2) - to your personal wallet. So when some chunk of your savings gets unlocked, you can either spend it (releasing txB2), or simply freeze it for 1 more year by releasing txB1 which will do similar thing as txA did.
|
|
|
|
I'm going there too, but Amir Taaki never replied and looks like conference is cancelled. |
|
|
|
Now I know why OP_VERIF and OP_VERNOTIF fail the transaction even if "not executed". BitcoinQT walks though all operators from OP_IF to OP_ENDIF inside "non-executed" branch to keep track of nesting. Since OP_VERIF and OP_VERNOTIF are not assigned, even inside a non-executed branch they will fall in "default:" switch case and cause the script to fail. Some other ops like OP_VER can be present inside non-executed branch because they'll be skipped. OP_IF = 0x63,
OP_NOTIF = 0x64,
OP_VERIF = 0x65, // Not assigned.
OP_VERNOTIF = 0x66, // Not assigned.
OP_ELSE = 0x67,
OP_ENDIF = 0x68
|
|
|
|
I'm looking at script.h in BitcoinQT, in a definition of ValueString() and see this: inline std::string ValueString(const std::vector<unsigned char>& vch)
{
if (vch.size() <= 4)
return strprintf("%d", CBigNum(vch).getint());
else
return HexStr(vch);
}
Which creates some ambiguity: it can output 1002003004 for both decimal number 1002003004 (which fits in 4-byte int) and for hex representation of 5-byte data 10 02 00 30 04. Is it okay? Do we have some other non-ambiguous encoding of data? I don't see any string parser in BitcoinQT, so maybe it's a non-issue, but bitcoin-ruby has a parser. In case of bitcoin-ruby, it only parses 2, 3, ... 16 as OP_<n>, while 17 would be parsed as 0x17==23. And data 0x16 (==22) would be encoded as "16" and then interpreted as 0x10 (== 16). In CoreBitcoin (objc implementation) I'd like to avoid ambiguity and be able to correctly parse human-readable scripts. |
|
|
|
|
Thanks for the links.
I've replied to your post about statistical escrow. What's this "even more insane" something of yours? :-)
|
|
|
|
|
How would escrow decide on increasing/decreasing the rating of participants? How would new vendor and new buyer (with no reputation yet) decide on amount of insurance deposit?
|
|
|
|
|
As I mentioned in the article, escrows need to be experts. That's not very cheap or possible in many typical cases. And some things are not possible to prove to an escrow or anyone.
|
|
|
|
|
I just got a feedback from a friend of mine. This is an attack that can be fixed.
When Bob sends his secret number to Alice, Alice now can use funds anytime. She can put this money into "long-term savings" because she is 100% sure she can refund them. And Bob would have to wait.
To avoid this problem, both parties can create a "destruction" transaction that spends all funds to 00000000000000000000000000000000000. This transaction would be signed by both of them, can be released by any of them any time (it may have a short lockTime to let people cool down) and will be invalid once any party spends their output.
The scripts will be like this:
txout1:
IF
AlicePubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY HashB EQUALVERIFY
ELSE
AlicePubkey CHECKSIGVERIFY BobPubkey CHECKSIGVERIFY
END
txout2:
IF
BobPubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY HashB EQUALVERIFY
ELSE
AlicePubkey CHECKSIGVERIFY BobPubkey CHECKSIGVERIFY
END
When this transaction is signed by both parties, Alice and Bob would construct and sign another transaction that spends these two outputs to a predefined invalid address. Once a person sees that deposit is in blockchain and he has a valid destruction tx, he begins executing his part of the deal. If any party decides to play bad, the other guy may threaten to destroy all funds. This solves the problem of non-releasing secret numbers for undefined period of time.
I'll update my blog post soon.
|
|
|
|
Hey, I've written on my idea how to make contracts with people who don't really know each other with low cost, no third party. Ideas based on NashX.com service. Special thanks to Mike Hearn for "Contracts" page on the wiki. http://blog.oleganza.com/post/58240549599/contracts-without-trust-and-without-a-third-partyTLDR: 1. Two parties independently lock some amount of money in a single Bitcoin transaction without meeting in person or trusting anyone. 2. This money can be unlocked only when both agree with that. If at least one party does not want to unlock the deposit, another party cannot do anything about it. 3. Both parties can unlock deposit only atomically, for both of them. No one can unlock just for himself. 4. No one else has access to the deposits and neither party can access other party’s money. Output scripts: txout1: AlicePubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY SHA256 HashB EQUALVERIFY txout2: BobPubkey CHECKSIGVERIFY SHA256 HashA EQUALVERIFY SHA256 HashB EQUALVERIFY HashA, HashB are hashes of the secret numbers of each participant. Numbers are revealed when they want to unlock the money. Amount of deposit should be 200-300% of the price. E.g. if the deal is about 1 BTC worth of merchandise, the deposit should be at least 2 BTC. NashX ask seller for smaller deposit (100%) because he sends first, but this doesn't seem "fair" for many people. So lets have 300% each, so it does not really matter who sends first. Parties can negotiate how much they lock up, of course. Ideas? |
|
|
|
I don't understand why the wiki says ( https://en.bitcoin.it/wiki/Script): OP_VERIF (0x65) Transaction is invalid even when occuring in an unexecuted OP_IF branch OP_VERNOTIF (0x66) Transaction is invalid even when occuring in an unexecuted OP_IF branch From the BitcoinQT code I see that OP_VERIF and OP_VERNOTIF are undefined in the same way as OP_VER or OP_RESERVED. Meaning, if OP_VER is skipped in the if branch, then OP_VERIF is skipped as well. But the wiki says that tx will be valid if OP_VER is not executed, but will be invalid even if OP_VERIF is not executed. Is it a mistake in the wiki or I miss something here? |
|
|
|
|
Show Posts
