Show Posts
|
Pages: [1]
|
I just had an idea for a Bitcoin game where the patron can prove the Website didn't cheat. I call it "BitReflector."
The user sends Bitcoin to an address, and the site instantly echos back 5% of the amount.
If the least significant hexadecimal digit of the transaction hash agrees with the least significant hexadecimal digit of the hash of the block containing the transaction, the site keeps your wager, otherwise it refunds it.
At 5%, it takes 20 plays to double your money, but it keeps your wager an average of once every 16 plays, giving the website an edge of 1.25%, which is very generous compared to the house edge of 2% typical of casino gambling games.
Since there is no way for the website to manipulate the block hash, which is generated by miners and is strongly pseudorandom, and this information is publicly available, undetectable cheating is impossible..
This game should be pretty addictive, given that it offers instant gratification and a generous payout, although like all popular games of chance, you will slowly lose money in the long run.
So a few questions...
Has anyone ever done this before? I see there have been websites like CryptoDouble and others, and casinos with verifiably honest casino games using message digests, but I don't see anything that is this exact scheme.
How legal would BitReflectors be in the US?
|
|
|
I think that sometime in the next year, we should hard fork the reference client to use something other than RIPEMD-160 to hash addresses from keys, and strongly encourage people to move their BTC to new transactions employing the new message digest function.
RIPEMD-160 dates from 1996, and was estimated to have a lifetime of around 10 years. So it's now 10 years past its original projected life. It needs to remain unbreakable for as long in the future as people leave transactions in the blockchain, which could be another 10-20 years.
Competitive message digest functions from the same era include MD4, MD5, and SHA-1. MD4 and MD5 have already had collisions demonstrated, and SHA-1 is deprecated, and the recommendation is to retire it sooner rather than later.
One suggestion would be to use SHA256d both for proof of work and hashing addresses. It is believed to be secure well into the future, and using a single function to do all hashing in Bitcoin wouldn't leave multiple instances of things that could fail. You could just take the lower order 160 bits of the SHA256d hash as the address hash.
If we leave things as they are, it is likely that sometime in the next 20 years, someone will demonstrate a computationally feasible pre-image attack on RIPEMD-160, and will be able to generate working Elliptic Curve keys from any address. Using SHA256 and using it twice was a wise choice by Satoshi, and we should move to using that as the address hash.
|
|
|
As someone who would vote "Yes" for Brock Pierce being on the Bitcoin Foundation Board, I thought I would outline my thinking on the subject, mostly for Phinnaeus Gage, Xtib, and others who express incredulity that anyone could hold such a position.
First of all, the events portrayed have nothing to do with "Pedophilia," which is a sexual attraction to prepubescent minors. They are about sex between adults and individuals in their mid teens and above, which while biologically normative, is proscribed in our society to prevent people in positions of power from taking advantage of people with little or no power of their own. Pedophilia is not about sexually mature people having sex with other sexually mature people, no matter how inappropriate or power-disparate such encounters may be. It is common in the gutter press and other places that should know better, to use "pedophilia" as a pejorative to refer to adult attraction to teens and as the name of a crime. It is neither.
So what is being alleged here, is that Brock Pierce knew individuals involved with, and was associated with a scene, where exploitative adult/teen sex occurred, at a time when Mr. Pierce was not much older than the teens allegedly involved.
Apparently, to some, like Phinnaeus Gage, this means that for the rest of his life, every time Brock Pierce tries to do anything, people must leap out of the bushes, point at him, and scream "Pedophile," and then post every single news story about DEN over and over and over again, day after day after day, until peoples eyes bleed.
This in spite of the fact that no credible evidence has ever been presented that Brock Pierce engaged in the activities alleged, sufficient to charge him with any sort of crime, and it is now decades after this dead horse should have been beaten to death with a shovel and buried in a deep grave.
The actions of self-appointed "pedophile outers" like Phinnaeus Gage teeter on the fine line between legitimate concern about the sexual exploitation of minors, and gay-bashing and hate speech, especially when interspersed with "Collins-Rectum" jokes. What's next? Snide comments about salad-tossing and how a microwave can't brown your meat?
The notion that Bitcoin, a unregulatable distributed Cryptocurrency, which has enabled a payment system for things like illegal drugs, assassination, and child pornography, is going to have its reputation sullied because someone is on its board, who, two decades ago, as a person in his late teens and early 20's, knew some people who liked to have sex with teenagers, is laughable. Really? Seriously?
I think Brock Pierce is a welcome technical asset on the Bitcoin Foundation Board, and those who are going to resign because he is there should, well, just resign. Preferably quietly, and with a minimum of self-righteous speech-making about whatever pedophile-uncloaking agenda they are currently flogging.
The major characteristic of all witch hunts is that the dissenters end up being accused of being witches themselves. Perhaps this is why so few people have opined on this egregious and inappropriate public airing of gossip and speculation about Brock Pierce's private business and sexuality.
I'd just as soon never see another thread on this topic.
|
|
|
People using Bitcoin to purchase merchandise don't care what the price is. They just purchase Bitcoin of value equal to what they want to buy, use it to pay for the item, and the merchant changes it back to dollars as quickly as possible.
These merchants and customers have no exposure to the long term price trends of Bitcoin. But what scares them is the real possibility that there will be a sudden 30% price drop while someone is holding the Bitcoin.
This doesn't happen often, but when it does, it creates a narrative which discourages Bitcoin's wider adoption for transactions.
What would be the pros and cons of Bitcoin exchanges adopting circuit breakers, where trading is suspended for various periods of time on movements of the Bitcoin price by certain percentages.
If people could be certain that the price movement in a single day would be limited to, let's say, 5%, it would remove the remaining psychological impediment to using Bitcoin to buy things in everyday life.
Taking a week to drop 30% wouldn't be a big deal to speculators, but it would give merchants and store customers insurance against taking any significant loss when things are bought with Bitcoin.
Please discuss.
|
|
|
If Mt. Gox ever rises from the ashes, there are some simple things it can do to avoid unrestrained market volatility.
1. Shorten the trading day.
There is really no need for a Bitcoin exchange to trade 24/7. It would be perfectly satisfactory to execute trades only between 10AM and 4PM Eastern, while letting people enter orders at any time. This would create periods during which trading doesn't take place, allowing analysis of market conditions offline, and the entry of stabilizing orders by those making a market in Bitcoin. With multiple exchanges, there would probably be somewhere you could trade any time of day, but trades on a given exchange should be limited to business hours in some chosen locale.
2. Circuit breakers.
It is absolutely absurd that the Bitcoin price was allowed to crash from $17.50 to $0.01 on Mt. Gox. It would be far better to automatically suspend trading for two hours on a 10% price change, and until the next business day on a 25% price change. This wouldn't place any limits on Bitcoin value long term, but it would preclude someone from suddenly manipulating the price by trading enough Bitcoin to wipe out the existing buy or sell orders completely.
What do you think?
|
|
|
Since Mt. Gox is unlikely to reopen, I propose starting a Bitcoin redemption service based on the wildly popular Cash4Gold business model.
Call our 800 number, and we will mail you a Bitcoin address to send your Bitcoins to. When we receive your Bitcoins, they will be assayed by our team of crack welfare mom metallurgists in a small room filled with lung-destroying acid fumes, whereupon a melt date and a monetary amount will be assigned to them, typically one third of their actual value.
If you choose to receive your funds via ACH, that concludes the transaction, and you have no recourse.
If you choose to receive a check and are dissatisfied with the amount, you may call us prior to your melt date, and ask to return the check and receive your Bitcoins back. At our discretion, we may attempt to renegotiate the sale for two thirds of the actual value.
To advertise, we will dig up and reanimate the corpse of famed pitchman Ed McMahon, who will be featured in television spots to advertise the service.
|
|
|
If we could make a stable market in Bitcoins at a price of 90 cents each, Bitcoins would take off as an alternative currency.
First, regular merchants could advertise that they accept payment for purchases from their store in either Bitcoins or dollars. This would give customers paying in Bitcoins an automatic 10% discount on their purchases. This discount for customers paying in Bitcoins, and the fact that the store accepts Bitcoins, would attract additional business to the merchant, and more than cover the cost of giving the discount.
Second, as long as merchants used their Bitcoins to purchase stuff they needed from other merchants also accepting Bitcoins, accepting Bitcoins wouldn't cost them anything at all. The 10% cost of converting Bitcoins back into dollars would only affect the last guy in the chain. This would suck dollars into the Bitcoin economy and keep the Bitcoins circulating.
Third, at a price of 90 cents each, early adopters who created and stashed hundreds of thousands of Bitcoins away back when mining was easy, have no chance of becoming Bitcoin Multibillionaires. They would have to settle for a modest reward for their contributions.
Bitcoins are presently trading at $15.80. What sorts of things could we do to incentivize them to trend towards their ideal value of 90 cents?
|
|
|
I was just reading some comments by Michael Rivero at the WhatReallyHappened blog.
"As a part of the mining for BitCoins, a huge amount of computer power is being spent on cryptographic processing of these blocks, and nobody really knows for certain what is inside those blocks.
I am concerned that the BitCoin miner, along with passing BitCoins hither and yon, is actually a vast distributed code key-breaker, as I cannot think of anything else requiring that kind of computer power (as NSA's rumored expenditure on exaflop computers suggests). With enough raw computer power chained together in a few million BitCoin users, brute-force breaking of the keys of asymmetric encryption becomes achievable, even convenient."
LOL!
|
|
|
I was surprised to see that Bitcoin passes untrusted signature data received from the outside world to openssl without doing any checking on it. This leaves bitcoin open to the Litttle Bobby Tables ( http://xkcd.com/327/) attack. Each signature has exactly one DER-encoded ASN.1 octet representation, but openssl doesn't enforce this, and as long as a signature isn't horribly malformed, it will be accepted. So you can sit on the network, watch for transactions, and echo them with the signatures slightly tweeked, but still valid. These new transactions will have different hashes, and will compete with the original transactions for inclusion in a block. When a cloned transaction beats out the original for block inclusion, it will leave the original in the owners wallet unconfirmable forever, resulting in inconvenience and unspendable coins. Quick echoing and network latency gives this a finite chance of happening. Of course, you can't create or destroy coins with this, and the money still winds up at the right destination. However, the typical user isn't going to know how to restore an old wallet and rescan the block chain to get his bitcoin client back to working condition. It might be a good idea to patch this before some enterprising person with excess time on their hands (cough) makes a cloned transaction echobot.
|
|
|
I've been pondering ways of layering useful things on top of Bitcoin, and was thinking of something along the lines of Ross Anderson's Eternity Service, which Adam Back did a Perl Implementation of a number of years ago layered on top of Usenet.
Now Usenet is a pretty persistent backing store, but it's nothing compared to the bitcoin block chain, protected by tens of millions of dollars in stored value. You can imagine the resistance if a TLA ordered a block chain takedown. Also, every single client has the entire block chain, giving total plausible deniability for anything encoded inside it, just like an NNTP server taking a full feed.
Now I imagine that there are probably some developers who feel that Bitcoin should be a currency-only system, and who will threaten to have a cow at the thought of Bitcoin being used for file storage. However, new uses are found every day for Internet protocols, and ordering people not to store small high value data sets in Bitcoin is about as practical as demanding people not download copyrighted content with Bittorrent.
So lets look at the economics of file storage in the Bitcoin block chain.
We probably want to keep blocks under 10,000 bytes in length. The obvious place to put arbitrary data is the address fields of outputs. If we pay a fee of 0.01 BTC, we can make the output values less than 0.01 BTC, and have as many of them as we want. Picking 280 outputs as a nice round number, and setting their values to 0 BTC, we encode 5800 bytes of arbitrary data in a block of approximately 9712 bytes in length for a cost of 0.01 BTC.
This works out to an encoding efficiency of just slightly over 57% and a cost of just under 1.79 BTC per megabyte.
As a proof of concept, I have two transactions in the queue which stego one of the Bitcoin logos into the block chain, at a cost to me of 0.02 BTC.
Append all the address fields in these two transactions together, and do a yEnc decode, and you will get back a file called "bitcoin.jpg".
Perhaps I could offer this as a service, at 5 BTC per megabyte, and make a small profit.
|
|
|
I discovered Bitcoin a few weeks ago, and have read the paper and the source code of the official client.
While playing with my 0.05 faucet bitcoins, and familiarizing myself with the protocol, I managed to get myself into some sort of deadly embrace in which I cannot do anything with my remaining unspent outputs.
In block 122026, in transaction 73, I claim an output of 0.05 bitcoins, and send 0.02 and 0.03 to address 1A8TY7dxURcsRtPBs7fP6bDVzAgpgP4962. In transaction 123 of the same block, I claim the 0.02 output from transaction 73, and send two outputs of 0.01, again to 1A8TY7dxURcsRtPBs7fP6bDVzAgpgP4962.
That gives me three unclaimed outputs, of values 0.03, 0.01, and 0.01, for a total of 0.05.
The first odd thing is that the official client displays my balance as 0.02 bitcoins, not 0.05. If I restore an old wallet with just keys in it, and let it rescan the block chain, it again computes the same incorrect balance of 0.02 bitcoins. The top two transactions displayed are out of temporal order, showing the split of 0.05 into 0.03 and 0.02 as the most recent, with the 0.02 into 0.01 and 0.01 after it.
The second odd thing is that the client lets me spend these 0.02 bitcoins without decreasing my balance, over and over again, and the transactions just sit there in perpetuity with zero confirmations forever.
Any transactions I generate involving these three outputs are accepted by my client as valid, and are broadcast over the network, but never get included in a block, even after days of waiting.
The private key for address 1A8TY7dxURcsRtPBs7fP6bDVzAgpgP4962 is, as a decimal integer,
62914421751202395784887832168971429678493304086217746188800433854666065869728
The associated public key is
04 9ba39856eec011b79f1acb997760ed9d3f90d477077d17df2571d94b2fa2137b f0976d786b6aabc903746e269628b2c28e4b5db753845e5713a48ee7d6b97aaf
Any ideas as to what is happening here?
|
|
|
|