Perhaps the right approach for betcoin would be to focus on an abstract concept called "conditional transaction" where a transaction takes place only when a certain condition is met at a certain time. The condition could be set by the initiator of the bet who chooses one of the predefined validation methods that the betcoin protocol would offer. It can be the "last price" or the "initiators decision" or anything that can be reliably and indisputably decided by any miner. The validation methods could even work as plug-ins that betcoin miners and clients choose to incorporate. If enough miners incorporate it then it becomes an official validation method.
Yeah, I think flexibility is a virtue here. This is exactly the idea of bitcoin's scripts. So you'd have an operator that pushes the initiator's value determination to the stack, and you'd have an operator that pushes the last price to the stack. The script logic itself is up to the sender of the transaction. Another cool operator would be a random number operation. That would allow trivial p2p lotteries and other games of chance. I was thinking you could base that on the nonce, because that would be hard to game for the miner. |
|
|
|
Very nice, this is why I still read this forum. The idea of letting the final outcome be decided in a self regulatory way by the last matched price is at least very intriguing, like all self-regulating schemes. In this case, however, it becomes almost philosophical: the sole and only thing that links a particular bet with the real world is its verbal description, the string that accompanies the bet-id. I wonder if that is enough to make this work. If it is, we would have a have a robust betting system and a proof of the power of words!
Considering the above loose connection with the real world, an issue with betcoin would be that the outcome of a bet could be determined more by the funds that one pours into it into one or the other direction rather than its description. As a thought experiment which i think would give some extra insight to if this would work or not, consider the following bet: "the outcome of this bet will be true". Or even: "this is an undefined bet". In such a case, I think, the bet outcome will lean towards where the most funds have been put. This is not what one wants when betting.
So in my opinion it is funds vs the power of words that will determine whether betcoin would work as proposed.
If you had described the bitcoin idea to me and I had understood it perfectly before it was tried, I think I'd be pretty skeptical about it working, at least to the degree it's currently working. I think the only way to know for sure if this thing has a chance is to try it, but I'm not as brave as Satoshi so I want to get some critical feedback first. I would guess that bets with vague descriptions wouldn't get a lot of market action, because everybody would know that the system wouldn't work well for those bets. If the bet was described well, say Redskins beat or tie Cowboys in next week's game, and somebody poured tons of money into the Cowboy side at the 2 minute whistle and the Redskins up by 21 points, people would either assume that they knew something very weird about the eventual outcome, or that they stand to make a lot of money betting against them. This would draw speculators like sharks to blood. After this happened a couple of times, I think people would realize it's a bad idea to go against speculators. Governments find this out all the time. On the other hand, if the speculators get killed and the closing price doesn't reflect reality, people will stop using this. Working on this project is a bet on the former. Another point I want to bring up is that there will likely be overlapping contracts for the same thing. So there will be arbitrage opportunities as well, and you'd have to game all of the different contracts. The contracts might not be identical, and could overlap partially with other contracts (there's a contract on whether the Redskin's starting quarterback is going to be fit for the game after an injury), so the interlocking pieces could strengthen the whole structure. A, perhaps less elegant, alternative would be that the one that initiates a bet also gets to decide its outcome. Let the market decide which initiators (identified by their key) it trusts and which it doesn't.
Yep, I could see that happening. But if this is totally anonymous there's nothing stopping the initiator from putting in a ton of sidebets. They would trash their reputation, but for big bets, the easy money might be irresistible. Homo economicus would fix the bet if the expected return from his side betting was greater than his perceived value of his reputation. It's also possible that wouldn't be a big problem, because of the enormous value of a good reputation. The other thing that bother me a bit about this is you might see concentration of power in a few entities, whereas betcoin strives to avoid that. That might be an impossible task though. |
|
|
|
I don't think this is correct. - You have the following 4 items: the private key (A), the public key (B), its associated hash (C) and finally the associated bitcoin address (D), which is base58encode( hash (C) + checksum). (D) is only invented so that the hash (C) is human friendly.
- If you know (C), you can calculate (D) and vice-versa. But is it not possible to calculate the public key (B) from (C) or (D).
- Initially to receive coins, you reveal your bitcoin address (D).
- If you send coins to it, a standard transaction is made to (C) (Humans do not really need to read the raw blockchain). Output from it can be claimed if you can sign the transaction.
Yeah, those are very good points. The compromised computer can already know that the bitcoin addresses you're sending from belong to the same account and that they belong to you (if the computer has any additional information about you). This could be an issue, and should probably be addressed by any scheme that purports to be secure. The only added amount of data it could glean from you requesting previous transactions for bitcoin addresses is that it could infer that you own bitcoin addresses that you may not end up using in the send transactions. |
|
|
|
However if the future said "This future should pay $1 if event X happens, but will actually just pay out the closing price", then there is nothing to force the future to the right price. If the price is 60c, then why would it drop?
Right, that's the exact question this hinges on. My hypothesis is that some kind of game theory magic would make this work. Trading is about the market coordinating to reveal expectations. The only thing the market has to coordinate on in these contracts is the event that it's about. You have no idea what the closing price of the contract is going to be, but you do have a good idea about who's going to win the football game. Would you bet lots of money against a redskins win contract if they're up by 21 points with a minute left to go? Speculators would be the key. You'd think they'd step in and make the bet against anybody trying to manipulate the closing price. It's also possible to make the closing price chosen semi-random by not picking the exact closing price but randomly picking the closing price from on of the last few blocks or something. I'm not saying this is a sure thing, but if it works it opens up amazing possibilities, especially for an automatic bitcoin-style p2p market that doesn't rely on any point of failure and can't be shut down. |
|
|
|
Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.
If the device does all of the wallet stuff itself, you can take it on the road. I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC. The only reason I can think of that you wouldn't want an untrusted client preparing the unsigned transaction for you is that you don't want to divulge any of your public keys that are holding money. But that means that if you receive money away from your trusted machine, you won't be able to spend that money. I think a combination makes sense. You can download a cache of your current transactions at home. When on the road, if these transactions can cover the bill, you don't need to divulge any public keys. Otherwise you have the choice of divulging public keys to the client to check for new incoming transactions until you can cover the bill. I'll release the link to my website as soon as the lightweight client is ready for testing.
Looking forward to it  |
|
|
|
Your real wallet is in the device. The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it. When you want to pay, it sends the destination address and the amount, only. The device then creates the transaction all by itself, using transaction records it already knows.
Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway. |
|
|
|
getPublicKeyTransactions -- why do we need that?
The secure device needs copies of all blocks involving keys that it contains, so that it can generate new transactions later. It would use this request to ask for them. As an aside, the secure device should only make this request upon a command from the user. That way you can plug into your home box, which is probably honest, and update your information, but when you plug it into a retail POS, you don't give it the chance to give you bogus data. But if you're getting the unsigned transaction, that will include the proper inputs. I'm not sure why you'd need all the previous transactions. The idea is that we don't assume anybody is honest. The secure device makes sure we're never doing anything except sending the displayed amount to the displayed address. It's impossible to do anything else with that signed transaction no matter what you feed the secure device. Unless the tiny spec I read was missing something, there was no way in JSON to authenticate, that detail being left up to the layer below. Since there is no layer below when using serial, either we make one, or we use digests to authenticate commands.
My first guess is that there is nothing in any of these commands or responses that needs to be kept secret, but a few things that we would like to have authenticated.
I'm probably missing something here. If we know the secure computer or device's public key and encrypt the whole JSON response with that key, what else do we have to worry about? In any case, all information being sent here is in the public block chain anyway so I'm not sure if there's a point encrypting it. |
|
|
|
You are betting "what will the market close at?". It would make no difference what was in the actual text of the bet was.
The reason betting market tend to go to the actual value is that no matter what price they close at, the exchange pays out based on the actual result.
I'm not sure about that. Why is the GBP/USD at 1.6? The exchange isn't going to pay out based on some actual result. Your payout at any given time is the market price. The only difference here is that there's an abrupt change in events. When a field goal is good at the end of a game the exchange rate will quickly change to very close to 1.0 for the winning team. But similar things can happen with stock and commodity options. The other part of my suggestion was to have a referee.
Actually, apparently, the bitcoin system can have more complex rules than just pay money to X. However, don't think it can have "split money between these people".
That's true. Bitcoin has scripting, but that scripting is very limited in the context we're talking about. For instance, the scripting can't affect the amount so you wouldn't be able to split payments. It certainly can't interface with a referee. But I don't think the p2p system should interface with stuff like that. It should stay deterministic based on the data it has itself. There's plenty of room to build systems around it that would make use of a referee. |
|
|
|
Step 1. Add some new methods to the JSON RPC API. I think I can get by with just 4, but I may have missed something. acceptPublicKey tells a node to add a new public key and include it in balance calculations. getPublicKeyTransactions tells a node to return all transactions involving a given public key. getPaymentRequest tells the node to give it any pending payment requests. returnPaymentRequest returns the signed transaction to the node.
acceptPublicKey, balance calculations -- I like that! getPublicKeyTransactions -- why do we need that? getPaymentRequest, returnPaymentRequest -- yep these are exactly what's needed to enable use with secure devices. browsing through the code shows that the relevant code that has to be split out is all in a critical block. the signed transaction will have to be checked for viability once it's imported back into the client. Another thing you'd want to be able to do is test the private key signing without actually doing a transaction. Step 3. Implement JSON over serial. Could be actual serial, could be serial over bluetooth, could be serial over USB, could be a terminal program on each box with the super paranoid user relaying commands back and forth by retyping them. I think we would need to extend the JSON spec, since it doesn't seem to contain any provisions for in-band authentication, and we won't have access to the HTTP layer doing it for us. I propose that each string be followed by a hash of the command + password.
Why do we need in-band authentication? Why not just encrypt the JSON with the secure device's public key? I think it's best to use established secure protocols like TLS if at all possible. |
|
|
|
You can just leverage Google or Facebook authentication if you want 2-factor on signin. That's a 2 hour job for any BitBank.
Ok, that's the missing piece. I think that's a pretty good option for Gavin's challenge. I'm not that familiar with Google or Facebook 2-factor authentication, but if people become comfortable using it via a mobile phone or smartphone and these cheap little devices become easily available, that would be a really nice system. I still like the idea of a secure usb device that obviates the need for the online service. It's a tradeoff of trust of a 3rd party service against the responsibility of securing your physical keys. You're right that it doesn't solve the case of an attacker who just wants to observe your bank statements and doesn't care about stealing your coins. I don't think anyone has ever solved that one, without assuming the web access device is trusted.
I never really expected that of the scheme. Most people don't have incredibly sophisticated keylogging, memory-reading root-kits on their computers and teams of hackers standing by to analyze the data collected from them. As long as your money is safe I think that's pretty reasonable for the average joe. |
|
|
|
If 90% of the miners used that rule, the effect is that you aren't actually betting on the result, you are betting on the market price. What if someone floods the market just before close?
Yeah, that's the basic assumption here. That the best measure of the result we have is the current market price. That's the assumption before the result is "known", so why not continue the assumption once the event has happened? Since as I mentioned before there isn't necessarily a clear cutoff of when it happened anyway. I don't think miners are ever going to be able to adjudicate even the simplest of outcomes, that's just not what they're about. That's why I'm interested in hearing criticisms of my scheme. |
|
|
|
@ben-abuya
A fully-backed options/prediction market imposes an implicit tax on transactions in contingent claims. This happens because speculators have to tie up the use of their bitcoin to participate in the market. Accordingly, they have to forgo interest until the predictions are realized. I'll explain in more detail later.
Yeah that's true. I still don't totally get the contingent claims stuff, and I can't think of any other way to guarantee a bet. I think this is mitigated by a potentially short term of contract and especially because bitcoin is deflationary. Maybe interest isn't as in important when your coin is deflationary instead of inflationary. How much interest do you expect to get on your savings now? What's the devaluation spread between an inflationary dollar and a deflationary bitcoin? Seems like the remaining interest you'd forego, if any, could be worth the utility of the prediction hedging. |
|
|
|
Note that unlike smart cards, these devices would not be customized per user. If yours is at home, you could just as easily use your friends.
How do you sign in to the online service? If you use a pass phrase there could be a keylogger. This doesn't sound like 2-factor authentication, because your device doesn't authenticate you. So it solves the trust problem (you know the transaction is legit), but a hacker could steal your identity and pretend he's you. |
|
|
|
There's no point having an overseer service without layering a naming service on top of Bitcoin. Addresses are opaque, and you probably get them via email, a web page, IM .... ie, via the compromised machine. It's not safe to use raw Bitcoin addresses obtained via an untrusted intermediary. For this reason the overseer must be given a human friendly name and the thing you verify (with secure hardware) must present that name to you, in such a way that the friendly name is always linked to the underlying Bitcoin address in an untouchable manner.
I'd suggest we start by re-examining the patch from genjix to support sending to named addresses. I don't think it's worth worrying about the details of how exactly keys are secured until there's a framework in place to handle address switcharoos.
I agree with this. It's not as fun as trying to defend against root-kits, but probably way more significant for the average user. That said, I still don't get why people are saying you can just have a service without a secure device. Mike, your solution included a device with a screen and a button didn't it? Or are you referring to another solution you posted somewhere else? Gavin's plan called for something you'd get in the mail in case the service went out of business. The only way you can pass on the hardware device is either to trust your computer or to completely trust the online service. To me, completely trusting an online service with all your bitcoins kind of goes against what bitcoin is all about. I also really like the idea of different kinds of bitcoin addresses. We're going to need this stuff for multi-signing and more advanced scripting. |
|
|
|
That's fine, no one is going to force you to. But some people will find it useful.
This is a design discussion, we're trying to evaluate what would work best for the average user, it's not about what I want to use. My question is why would people find this useful if they can get the same functionality from a device they'd need anyway? Any chance you could find that reference? I would love to see it, but searching for "hackable mp3 player" doesn't turn up the sorts of things I'm looking for.
Sure: http://forum.bitcoin.org/index.php?topic=17919.msg227691#msg227691By the way, I am actively working on the hardware device route. I know what capabilities it is going to need, and what the communication protocol is going to look like, but I haven't yet found a hardware platform that is both simple to develop on and capable of doing the crypto.
What about the cryptocards like this? http://www.gemalto.com/products/top_javacard/download/TOP_DL_v2_Sept10.pdfNot sure it has the exact curve bitcoin uses, but it's getting pretty close. |
|
|
|
You don't confirm the transaction. What happens is that the service fails to confirm bogus transactions made in your name by your (pwn3d) computer.
Ok, rereading Gavin I see that "give me a call on big transactions" is the external device. Also, the "something I get in the mail" is an external device. I'm not sure it's worth going through all this, risking small transactions, getting telephone calls, relying on a 3rd party site, when you could just plug that something you get in the mail into your usb port and be quite secure from the start. The usb device could even auto-sign small transactions (no need to press the button) and keep track of how many transactions are being sent every day and notify you if something is weird. Someone mentioned that you can hack a $20 mp3 player and install your own software. It's already got a display, input device and usb plug. If you did want to implement Gavin's idea, bitcoin already supports multisigned transactions. You'd require 2 of 3 signatures. One on your computer, one kept by the service, and one in the thing you get in the mail. The partially signed transaction would have to be sent to the online service for the 2nd signature, and the service would forward it to the bitcoin network. |
|
|
|
Looks like the two approaches are completely different.
One doesn't require the user to have to buy/build any specialized hardware. The other doesn't require the user to rely on an external service.
The bitcoin world is big enough for both approaches to make sense at different times or to different people.
And I must say that after looking into actually implementing ECDSA on tiny hardware, I'm really, really warming to Gavin's idea.
But there is no approach in which you only need an external service and no external device. If the root-kit has control of your computer, you can't trust anything on the computer, not even an https connection to a trusted server. How will you confirm the transaction? Or is the root-kit confirming it for you? Or are you confirming it, but to the wrong address? I think the idea of an external device is a good one, since it's much easier to secure than your home computer. You don't have to implement ECDSA on tiny hardware, there are already smartcards available with this capability. |
|
|
|
cunicula, I like the work you're doing here, although I haven't grasped all the details yet. Are you sure you need miners to selectively mine different maturities and for them to have different difficulties? That would really complicate the system. I have a proposal for a more generalized prediction market based on the bitcoin concept: http://forum.bitcoin.org/index.php?topic=10011.0 |
|
|
|
|
Hmm, if we have the device with the screen and button, why do we need the BitBank? Since the only way to spend any coins from your account is to see the recipient address and amount on the device, and confirm with the button, what does the BitBank bring to the table?
I agree about the user friendly addresses. That might be a major hacking vector in the future because people aren't good at visually identifying those addresses. Something graphical would allow humans to leverage our brains' impressive image processing and pattern recognition capabilities. A strategy of running some 2d transform on the address and turning it into a colorful picture might be cool. Of course then hackers would try to find an address that produces a similar looking image, but maybe it's possible to make that hard. Another good approach is to add whitelisted addresses to the device as you make payments. You could also have trusted services that provide whitelists and text mappings to addresses, kind of like https domains.
|
|
|
|
|
What people don't seem to realize is that distributing a new currency to the world from zero is a really hard problem. In fact, before bitcoin came around I couldn't think of any viable way of doing it. Bitcoin's way is pretty brilliant and is working out swimmingly so far. And, by the way, if you're writing on the forum at this point, you are in all likelihood a very early adopter. The people who start buying at $100 and $1,000 per btc will be seeing you as a rich tycoon who got tipped off early.
|
|
|
|
|
Show Posts
