I have created a meetup.com group for Bitcoin in Israel, http://www.meetup.com/bitcoin-il/. The first meetup for this group will be on January 4th 2012 at 17:00, in Cafe Joe, Yad Harutsim 14, Tel Aviv. Upcoming meetups:A meetup organized by IBM, "Blockchain Is Open for Business", has been scheduled for September 7, 17:00, in Rise Tel Aviv. Gathering at 17:00. Details and registration at http://www.meetup.com/bitcoin-il/events/233564342/. |
|
|
|
This still gives big miners too much power in demanding draconian tx fees.
Please, keep in mind that there's nothing we can do to prevent such kind of "cartel boycott" from happening right now. If we don't need to rely on a cartel to maintain difficulty equilibrium, we can try to come up with a solution to the problem of a cartel forming. While individual people might have a slight interest in protecting Bitcoin from attacks, that interest might not be very strong. In an overall group, that means that the protection is pretty weak. For example, think of your average 1-rig miner out there right now. If Bitcoin collapsed today, how much of an impact would that really have on them? How much would they really lose?
Yes, this is the problem. No, I don't agree that a cartel is a desirable solution. |
|
|
|
No. The essence of Bitcoin is that its value floats, it is not tied to a dollar value, its value can go up or down due to market forces.
However, I would think that within an hour, the price will "probably not" swing very greatly.
3% is "Great". 3% is probably much less than what it would cost you to hedge against the risk. It's also less than what it would cost you to use an alternative like PayPal. And remember, as opposed to these options, it's not a 3% loss, it's a 3% fluctuation which could be either up or down and in expectation makes no difference. |
|
|
|
I will just give a grasp on the idea of these insurances for those who haven't heard about it yet. Basically, people interested in not being the target of double-spends, as well as being capable of spending at all (the "freezing the network" attack scenario), could hire insurances for that. Say, for example, some organization wants to freeze bitcoin's network with a >50% attack. If that happens, insurers would have to pay a huge amount to their clients. They have a financial interest to rent enough processing power to outcome such attack as quick as possible.
Sorry, I'm just not seeing it. Relying on these insurers to counter any potential attack seems only one step removed from dropping the whole proof of work thing and just letting a few trusted servers synchronize transactions. I'd much rather see a carefully planned incentive structure / branch selection criterion (which IMO should involve some combination of proof-of-stake, cementing, Bitcoin days destroyed and proof-of-work) which naturally leads to an efficient decentralized market. (actually, I would expect most bitcoin users to collaborate... not only for ideological reasons, but simply to be able to spend their money again)
The effect each user's mining has on his own ability to spend bitcoins is negligible and not much of an incentive. That's pretty much what "tragedy of the commons" means. If you want a more "discussed" scenario which can be compared to bitcoin's "transaction fee tragedy of the commons" scenario, I'd suggest the one of stateless defense. It's obviously not exactly the same thing, but I think it's the closest one on economic literature. For example, half of the The Chaos Theory book, from Bob Murphy, is about stateless defense.
Thanks, sounds interesting, I'll try to have a look. If your solution relies on a cartel of miners boycotting competitors who undercut them, with nobody having a clear idea what they need to do to have their blocks accepted, I'd say you already lost.
And, what do you mean with "nobody having a clear idea what they need to do to have their blocks accepted"? Nothing needs to be done on secret, actually pool operators would better announce everything they do pretty clearly since they are using other people's resources after all. This still gives big miners too much power in demanding draconian tx fees. Which solves the difficulty equilibrium problem, but creates a new problem. (Fees too high will reduce Bitcoin tx volume and thus the total fees collected. But I see no reason why the point with the max collected fees is the point best for Bitcoin in general. Efficiency is when you compete with someone other than yourself.) And, also, what did I lose?
Lost in your efforts to bring about a decentralized (as in, not run by a cartel) currency. |
|
|
|
And the transaction fee "tragedy of the commons" scenario would probably be better solved by market agents (like insurers)
Can you explain exactly how will this work? Back then I was not at all convinced by Mike's vision of the mechanics, and I still consider this an open problem. Plus, if they want, they can actually use the same mechanism to try to boycott miners which accept transactions with "too low fees". "I won't mine on top of blocks which had transactions paying less than X/Kb unless it is already Y blocks deep". That would be another "decentralized" way to deal with the incentives issue, besides the eventual insurers.
If your solution relies on a cartel of miners boycotting competitors who undercut them, with nobody having a clear idea what they need to do to have their blocks accepted, I'd say you already lost. |
|
|
|
(I sense the marketing direction will be less about bitcoin as money (enemy: USD) and more about bitcoin as a payment system (enemy: paypal))
very true. Bitcoin is not a threat to the dollar. Bitcoin is a threat to the Banks and their stupid fees! <sarcasm> The bank is dead. Long live the new bank! </sarcasm> As I've said before, Bitcoin can only be a threat to banks if it is a threat to the dollar. If not, then whatever service is used to store a dollar balance and convert it to bitcoins and back for every transaction, is in fact the new bank and will suffer from all the problems of existing banks. I don't disagree with the principle though, widespread adoption of Bitcoin will probably start with using it as a payment mechanism while only holding a small amount of it at any given time. |
|
|
|
Thanks for your answers. However, you've created one more question, which is probably a duh one: How do you -rescan?
Assuming you're on Windows, one way to do it is by editing the Windows shortcut that runs Bitcoin. If you open the shortcut properties you should find that the target is something like "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe"
Replace this with "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" -rescan
And run it. Afterwards you should remove the -rescan from the link (loading will be slower if you keep it). |
|
|
|
Is there some website I can go to that tells me what bitcoins, solidcoins, litecoins, ixcoins and namecoins are all worth in relation to eachother?
For example:
How much is 1 solidcoin worth in bitcoins?
Etc.
Does such a creature exist in nature yet?
Several cryptocurrencies are traded at https://btc-e.com/ so you could look at prices there. Also http://bitcoinpie.com/ tries to summarize some of the information. http://blockexplorer.sytes.net/ gives some information on many currencies, but not the exchange rate. |
|
|
|
1) I have the bitcoin client downloaded on 2 different computers. How do I, if I can, use the same account on both of them? For the record, I have only used one of the clients so far (to obtain, but not yet spend, coins), but prefer using the other one. If I have to ditch one, can I transfer my coins to the other?
It's not recommended to try to use the same wallet on more than one machine. Consider using remote login or an eWallet service. To move permanently to a new machine, you need to locate your wallet.dat file in Bitcoin's application data directory and move it to the new machine. Make sure that Bitcoin in the old machine doesn't try using the file after you've copied it. The first time you run Bitcoin on the new machine with the copied wallet, use the -rescan parameter. 2) Suppose I need to do an OS recovery on my computer, and have to re-install the bitcoin client. How do I recover the public and private keys, or are my coins lost? For the record, I have downloaded the truecrypt program, so I can make a backup of my wallet on a thumb-drive.
After you reinstall Bitcoin, delete the wallet.dat file it has created and put instead the file in your backup. Use -rescan the first time. 3) How can I access my private key? The only key I see in the client is the one in the receive coins page, which should be the public key, as private keys usually begin with a 5 (according to the wiki).
This isn't something the Bitcoin client supports. You can use pywallet for that. |
|
|
|
Oh and while thinking about that I have become a bit worried about Bitcoins future. If an attacker would begin to mine Bitcoins in a very sophisticated, optimized and efficient way (I am not talking about breaking SHA or anything) and sell them cheaply, probably even at a minor loss this would at a certain point make it unprofitable for others to mine. This would be way below 50% of the network's hashrate, but would cause people to stop mining, because of being inefficient. I know there are people who have interest in Bitcoin and would still mine, but with a big bunch of people leaving an attacker would be able to create even more Bitcoins making his attack even more efficient would have it much easier to get past the 50% to mess the network up. So an attacker doesn't have to get to the 50% right away. It would probably be way easier to start a a lower rate and cut out the others.
An attacker whose aim isn't really making money in first place, but to destroy Bitcoin could do such a thing and therefor wouldn't really require the 50% right away, correct?
That's correct. I don't think it will give the attacker that much of an advantage though, most miners should have a sizable operating profit so will continue to mine even with this reduction in profitability. If the attacker waits too long he risks Bitcoin increasing in popularity (and price) and attracting more miners than before. |
|
|
|
Is there a different way to aggregate several hash functions so that the resulting function is assured to be safer than any single one?
Concatenate them (or parts of them). If you concatenate parts of them you don't get the same security. If you have 8 functions of which 1 strong and the others are weak, and you take 32 bits from each, I think this can be weaker than just the strong function. Sorry, I was referring to !a XOR a. Unless your difficulty allows allows every nonce, no nonce is possible.
You should always quote the comment you're replying to. Unquoted comments should be assumed to be replying to the original post. |
|
|
|
If you use the different hash functions separately and then XOR the results, you get a hash function which should be stronger than any single one of the original functions used.
Oh really? So if I use SHA256 as one of the hashes and the other hash is just reversing the bits then the XOR of the two is stronger than SHA256? Yeah, well, except for that  Is this a problem in practice? Is it conceivable that such dependencies exist between the named hash functions? Is there a different way to aggregate several hash functions so that the resulting function is assured to be safer than any single one? That would make it awfully hard to find a nonce.
This isn't a problem, it just means the numerical value of the difficulty will be lower. The cost of computing a hash can be thousands of times more than SHA-256 without having any consequence. |
|
|
|
Out of topic, is combinations of different hashing algorithm harder to break?
For example, is using SHA1 and then SHA256 harder to break in comparison with only SHA1? Or it depends on the weakest hashing (say md5), or the strongest hashing, or it depends on the order of the hashing?
If you use the different hash functions separately and then XOR the results, you get a hash function which should be stronger than any single one of the original functions used (Edit: With caveats). |
|
|
|
Can you make a do-it-yourself tamper-resistant connection? Even if so, anyone accepting the combined pieces would have to verify each and the sum, which seems even more annoying than checking a single physical coin sealed by you. Say I buy two of your coins and swap tokens, either by mistake, or maliciously.
The bar and the coin each have a clearly visible serial number, and the combination will only be accepted if the serial numbers match. The manufacturers of the bar and the coin make sure to be synchronized between them so that matching items indeed can be use to redeem the address. I agree with Cbeast that if bitcoin goes mainstream, physical bitcoin will be a novel collector item at best, an untrusted nuance at worst. I'm not so sure. Physical currency is convenient for some people/applications. If they can be manufactured cheaply enough and with a small enough form factor (maybe so much so that they can only be redeemed by dedicated machines) and the trust issue is solved by multiple partial keys, they'll find a use. In NYC we saw a demo of bitbar, a bar holding a private key in the form of rotatable magnetic elements. I wonder if these can be used instead of printed keys and holograms. |
|
|
|
Alice generates two 256-bit random numbers, X and Y. She uses X as a private key, and sends her bitcoins there.
Alice gives Bob X+Y.
Alice gives Charlie X-Y.
Alice gives Dave 2Y.
Nice. Seems to work as far as I can tell. It doesn't really allow anything that wasn't possible before - Alice could just encrypt a private key, distribute the encrypted copy everywhere, and create an m-of-n shared secret for the password. None of them know who has what. When they get together, they use a utility and basically brute force all the combinations (there aren't that many, like six) until they find the funds left by Alice.
Doesn't seem to be a security risk if they do each know what they have. Can't you just use a transaction script that requires 2 of 3 signatures? I think is a bit different to 2 or 3 signatures. M of N transactions allow no individual to access funds. This use case Alice always has access to the funds, with the added benefit you could implement this right now. I'm not an expert on Bitcoin scripting but it should be possible to have a script that says "either a signature from this address, or 2 signatures out of these 3 addresses". Anyway, the OP's protocol has the advantage that there is less data in the block chain and no need for either different transaction types or fancy stuff like OP_EVAL. Another simple scheme that would work for M of N where the desired M is N-1 for any N would be as follows:
Alice generates N large prime numbers (no limit on size), and gives one to each person, as well as the product of all the primes. The bitcoins are sent to a private key consisting of the hash of all the factors sorted in ascending order.
If N-1 of the people get together and share their numbers, the missing factor can be determined by simple division.
You could also use a scheme like in the OP for a general M (I haven't thought it through but it should work). Alice chooses X_1,...,X_M and sends to the address corresponding to X_1. She sends to participant k the value $\sum_{i=1}^M i^k X_i$ (each knows what his serial number is). If M get together they have a basis for F^M (see Vandermonde matrix) so they can find X_1. If there are less than M then their set does not span (1,0,...,0) (otherwise the Vandermonde matrix with this row added would be singular) so they cannot find X_1. This should be extendable to the case we don't want Alice to know the private key (maybe using homomorphic encryption). In case you're unaware, there's work (spearheaded by Stephan Thomas) to create a protocol that uses ECC magic to have m-of-n transactions with a single signature and without having to recombine the private key, so the address can be used repeatedly while maintaining the status that m participants are required. |
|
|
|
What I think would be interesting is to verify:
y^2 mod p = ( x^3 + 7 ) mod p for G:
1) Calculate y^2 mod p, get answer
2) Calculate ( x^3 + 7 ) mod p, get answer
I believe that answer from 1) should equal answer from 2)
Yeah, this pans out. y^2 = 1067362225016502275772194909503713869376985974142797512091458491530306631211206623652669436957676354343630306950631573032330832513385319878364322508915776
y^2 mod p = 32748224938747404814623910738487752935528512903530129802856995983256684603122
x^3 + 7 = 166977061698153803977729810299616665720111080589888563362701662779994291659333477169534477572723704285154275133397811778652651956291844366636068483203593094558427352525126936769086968791554813695916119291254705683450242657305024007
(x^3 + 7) mod p = 32748224938747404814623910738487752935528512903530129802856995983256684603122
|
|
|
|
I agree the 10% is amazingly high! and Bitpenny was PPS with 10% fee. Later Bitpenny was hit by a bad luck run and had to close because 10% turned out to be not enough. That's one of reasons why I decided not to make it lower. It's only "not enough" if there isn't enough reserve. In AoBPMRS I describe the reserve needed at a given fee level (or vice versa) to make bankruptcy probability arbitrarily low. Didn't anyone here hear about pool-hopping? I don't know how big the problem is in Deepbit specifically but those looking for a small proportional pool could easily suffer 20% loss. Use a hopping-proof method like PPS, PPLNS, DGM, shift-PPLNS. |
|
|
|
3: The payment/reward is simple cf Slush for newbies. different methods, not one necessarily better than the other.
The proportional method used by deepbit is necessarily worse than all others. If a newbie really wants simplicity he should go for PPS, preferably in a pool with lower fee than deepbit's 10%. |
|
|
|
This is genius and deserves a bump.
To be "genius" it needs to be both good and novel. This application (using the block chain to prove that a piece of information existed at a given point in time) is good but well-known. Also it can be done much simpler than in the OP. Since you don't need to be able to actually redeem any sent coins, you can skip the private key completely and simply include the document hash as an address. |
|
|
|
|
Show Posts
