Show Posts
|
Pages: [1] 2 »
|
I'm confused. Can someone more familiar with market trading explain current observed behaviour to me?
When Bitcoinica was in full swing, I understood the ask walls. You go 1000 BTC short at 10:1; then you put a 10000 BTC ask wall up on Mt.Gox. You rely on that wall to drive the price down, then collect your Bitcoinica short profit.
There is now no Bitcoinica. What does the owner of the 10000 BTC ask wall want to achieve? If you own a lot of bitcoins, don't you want the price to go up?
I'm not complaining about the walls, the people posting them are as free to trade as anyone else is; I'm simply confused as to what they are trying to achieve. Perhaps I am simply not thinking evil enough... could someone who is more evil than I out there tell me what I'm missing?
|
|
|
I've mentioned it here already, but it's worth it's own topic I think. Why don't all exchanges have an optional field for us to upload a GnuPG public key? In particular, one that matches the email address registered on the account? As in the recent Bitcoinica case, and the original Mt.Gox hack, return to service is highly dependent on verifying identity. The OpenPGP system has been around for years and works very well. What's more, the exchanges could periodically sign those keys offline for themselves -- then, in the event of a complete database breach and potential alteration they would be able to verify every single identity, detecting those that a hacker had tampered with and able to restore the original owner reliably It sometimes takes an event like these hacks to trigger a change of culture. Perhaps this Bitcoinica hack could be the impetus for other exchanges to use digital identities, which are, let's be honest, far more secure than a scan of a passport (it's not difficult to photoshop a scan to whatever you want). Wouldn't we all feel more secure if we had a reliable way of proving our identity to the exchange whenever they think activity is suspicious? What would it take for the big four, Mt.Gox, Intersango, btc-e and virwox to simply add a field to their databases?
|
|
|
Over the last year or so I've been writing a book on photography.
I actually only did it as a project for myself, with no intent to even show it to anyone else; but it is now approaching completion and it occurred to me that it might have value to someone somewhere. Being an evil capitalist pig, that implied to me that I should try and sell it.
It would be, basically, a PDF for sale for some nominal number of BTC. Given that it was never intended as a money maker I wouldn't want to charge a lot for a copy, nor to bother with DRM.
Selling work like this is completely new to me, either traditional or bitcoin. Does anyone here have experience of selling a book for bitcoins (I'm not interested in fiat, only bitcoins)? What are your thoughts?
|
|
|
People are talking about multisig support as if it would have prevented the recent thefts. It probably would have; but it would be nothing to do with multisig. That same security is (mostly) already available. Here's what Gavin said in the Ars Technica article: Under the new system, wallets would contain only one of two private encryption keys needed to spend coins. The other key would reside on a separate machine at a different location. Software on the second machine would scrutinize proposed transactions to make sure they're legitimate, and wouldn't send an entire payment all at once.
In other words: a second secure machine is needed to approve a transaction. Let's say it's as simple as a message popping up on your mobile phone saying "approve the following withdrawals". In multisig, answering "yes" would sign the transaction with the second private key. That would definitely be great. However, what is to stop the single current signature required being obtained in the same way it will be in this multisig world? No private key stored on the "hot" wallet; the mobile phone app stores the private key and signs on demand with approval from the owner. Now imagine that that app was in Zhou or slush's pocket. This is not to say there aren't additional advantages to multisig (prevention of damage on theft of mobile phone being one), but the above would have prevented the thefts without needing multisig support to be ready. There are already people doing this: BCCAPI as used by BitcoinSpinner, Electrum, StrongCoin, Blockchain.info -- they all do off-server transaction signing.
|
|
|
This bot is just filling the order history with noise; slowing down the server and making the price chart less informative for the rest of us. Here's the fix, Mt.Gox programmers: $MIN_TIME_TO_NEXT_TRADE = $ARBITRARY_CONSTANT / $BITCOINS_IN_THIS_TRADE
If someone wants to trade 0.0001, they still can. But they should then expect to wait 0.01/0.0001 (Using CONSTANT=0.01 for my example) or 100 seconds until their next trade. For anyone trading a reasonable amount, the time would be so small that it wouldn't affect them.
|
|
|
So, there's bitcoin prices ticking up quite nicely, when someone with enormous deep pockets dumps 25k coins; driving the price to 5.3.
That's fine. I'm not one of these people who hates on "the manipulator". The order books show a load of bids; and the manipulator is perfectly entitled to take them up on their offers.
Here's the thing though... the ask side fills up instantly behind the huge drop; and that's our fault. If you valued your bitcoins for sale at $5.65, or you were holding out for a profit at $5.7 don't suddenly accept a loss because someone takes a dump.
If you were running a business you would value your product and you would offer it for sale. Do the same with your bitcoins.
The worst of it is, that the person taking a dump wants us to fill in the ask side after they dump -- that's why they're doing it. The only way we'll stop this sort of behaviour is by making sure it's not profitable for them -- it's not profitable for them if it is profitable for you. Remember that and the "manipulator" has nothing to work with.
|
|
|
I accept that the following is bordering on paranoid wibble...
I just noticed, with the large trade that kicked us back up to 5.85 that the timing is suspicious.
It's suspicious because Mt.Gox seem to kill their live feed process (I hear because of a memory leak) once an hour. The big trade happened seconds before the hour.
Is someone trying to make trades at the exact moment that bots all get disconnected?
Has anyone else noticed what times big trades start?
|
|
|
I've been thinking hard about how Bitcoinica works, and can only conclude that it's completely flawed. I hope I'm wrong, so here's my reasoning: Imagine that Bitcoinica has no reserves. Mr Short, and Mr Long trade positions with each other at a price of $5 for $50 and 10 BTC respectively. The trading pool at this point holds $50 and 10 BTC. Price 2.5 3.75 5 7.5 10 Net long / BTC 0 6.67 10 13.33 15 Net short / BTC 30 16.67 10 3.33 0 Net long / dollars 0 25 50 100 150 Net short / dollars 75 62.5 50 25 0
When the price falls to $2.5, Mr Long is forcibly liquidated; that must be done by trading on Mt.Gox. Mr Long's 10 BTC (which is still in the pool) gets converted to $25, and stored in the Bitcoinica fund pool. Mr Short's position at that moment is therefore fully backed, there is $75 in the pool. What if price continues to drop though? When price is $1, Mr Short is expecting to get his original $50, plus $50 profit. The pool only holds $75 though. The answer is of course, that when Mr Long was liquidated, no trade on Mt.Gox can have happened. Instead, someone else must be found to take over his position. That liquidation required a new party to buy 10 BTC at $2.5, leaving the pool with $50 and 20 BTC. Who is going to take that on though? Bitcoinica has dealt with this problem by introducing its reserves, and upon liquidation it takes on the counter party position using those reserves. That is an unsustainable though, those reserves are not infinite. Travel backward in time, when bitcoins were $0.01 and imagine you had gone long (1:1) with 100 BTC. That required someone else to go short for $1. Now BTC are $6 each; and you are worth 200*6 = $1200; at some point that shorter was liquidated, losing their $1; but that leaves us $599 lacking in the fund pool. Now imagine that same was done at 1:10 leverage, there is no way to magically create the backing for the profits that are due, and Bitcoinica would have had to find (1900*6-1) to cash out the long position. When the market moves a significant amount, Bitcoinica's reserves will be insufficient to cover the profits that participants are expecting. Forced liquidations would need to happen in both the negative and positive directions. When your counter party is liquidated; that is the end of the game for you too, but you end up in profit. Is no one else suspicious at the admitted losses Bitcoinica made during the huge bounce last week? If Bitcoinica is working correctly, it should always make money.
|
|
|
A thought occurred to me about why Bitcoinica might be causing it's own problems (i.e. it's running out of reserve constantly).
The problem is that trades on Bitcoinica aren't moving the market. Because it's matching orders internally for the majority; then only the overflow into Bitcoinica's reserves ever makes it out into the order book. Until that point the price on Mt.Gox doesn't move.
Imagine a world were Mt.Gox had margin trading at 1:1.
You want a 10 BTC short but you have only dollars; you have to borrow BTC, then sell them. That sale moves the market somewhat.
You want a 10 BTC long but you only have BTC; you have to borrow dollars, then buy BTC with them. That buy moves the market somewhat.
With Bitcoinica, market sentiment doesn't move the market. Let's say the market thinks prices should be $10, but they are $5, as more and more people go long it should be buying BTC at the market place. Those "buys" push the price closer to $10, making the long slightly less attractive.
You might argue that it makes no difference; but it does. A long and short are not precise opposites, just like bid and ask aren't. They each only move one half of the market. That means the spread is much smaller than it should be because it is hidden away.
Strangely, I think it's bad for Bitcoinica too -- the fact that a "*" is appearing means that the market isn't compensating for preponderance of "longs", so Bitcoinica eventually has to dip into its reserves to keep supplying them. Eventually, those reserves must run out. If the market moved, then the long becomes less profitable and less certain.
Going long is a market moving action that, at present, doesn't move the market.
|
|
|
This is only a casual thought; I'm certainly not anywhere near being able to roll it out. Problem: a lot of noise gets made about two risks for average merchants who want to accept bitcoins. - I can't take bitcoins and give goods instantly because they might be double spent
- I can't take bitcoins in place of fiat, because by the time they've cleared to my exchange account and I've sold them, the price volatility means I might have lost money.
Solution: me. I'm considering starting a service that takes these two risks on the chin on behalf of a customer. Pay me some percentage (TBD) of your bitcoins and I will instantly credit you with dollars (at a quoted rate) or bitcoins. I want to gauge interest. If you offer your widget for sale for $23; you contact my website (say with a mobile app), and it looks at the volume available and says "I'll give $23 if you send 10 BTC to $SOME_BITCOIN_ADDRESS". That quote is then fixed in stone, and provided the transaction happens within some defined time limit, I will guarantee you your $23. Similarly for a double spend prevention. "I'll give 9.99 BTC if you send 10 BTC to $SOME_BITCOIN_ADDRESS". The 9.99 BTC is guaranteed. Essentially, I'm thinking it is insurance. On the whole, most trades won't be double spends, and there won't be huge movements, and even if there are, they will average out. Therefore I can offer to take the risk that the merchant doesn't want. Obviously it relies on the merchant trusting me; but that's something that only established with time and evidence.
|
|
|
An idea that I don't have the time for, so I gift it...
One disadvantage that Bitcoin has over banks is that at the end of the month the bank sends me a statement and I can see what I spent my money on. This is convenient as I can store it away, don't have to do any work myself at that moment but can still do my accounts years later.
With bitcoin, if I don't make a note of what any particular transaction is at the time, then I will have no clue in ten years what I bought. All I'll see is an address. I guarantee that most people are not disciplined enough to write appropriate notes on every transaction they make; and even if they were, bitcoin does not compare favourably with their bank if they are forced to do so.
So, could we create a distributed "receipt" system, shopping cart interfaces would, upon payment from a particular customer, know what bitcoin transaction hash paid a particular invoice. Could that information be published to a distributed database (a centralised one would be fine too)?
Of course people don't want the details of their transactions being published for the world to read, so the receipt database would encrypt the incoming report (or the shopping cart interface can do it for extra paranoia) using the address(es) in the transaction (which are nothing more than public keys). The only person then able to decrypt those details is the owner of the private key that matches... i.e. the person who spent the coins.
Bitcoin clients could query the receipt network when relevant transactions are received, decrypt the message and copy it to the local log. Being that the message is copied, the receipt server doesn't need infinite storage, just enough to give people who want the facility long enough between client runs to grab the data.
Voila: automated bank statements from Bitcoin, but completely secure, completely distributable.
(I think ECDH + AES can be used for this)
|
|
|
I ask this only half seriously.
Would it be sensible to ask of our exchanges and online wallets that they post a regularly-updated link to an encrypted version of the wallet.dat that they use?
Is the encryption from, say, GnuPG, solid enough that we could trust that it wouldn't be broken, while at the same time making us all feel a little more secure that a mybitcoin/bitomat situation at least has a potential resolution in the event of a catastrophic failure?
I suspect that anyone who implemented such a policy wouldn't ever need to take advantage of it (having done the work, you would certainly make it email you a copy of the backup as well) -- but it would publicly demonstrate that a backup exists, making us all feel a little more secure (only a little though).
|
|
|
Let's say I am an owner of gold and a seller of gold certificates. People would like to use gold, but it's hard to buy and sell things with it. I am honest; and trusted (people already buy my certificates).
Enter: Bitcoin (technology).
Forget Bitcoin as it is now for a second. Bitcoin's blockchain lets us trade anything securely; the only caveat is how that "anything" enters the system.
Remember, I'm trusted and honest. I get together with all my trusted and honest friends who also have gold. We all declare how much gold we have (by weight) and we all certify that those declarations are valid.
Now... we modify bitcoin to create a new genesis block (and hence chain) which issues exactly the agreed amounts. We all independently write those amounts into our genesis blocks (that way no one can cheat, since we all independently create the same genesis block). We all now run our bitgold nodes. We could have coinbase transactions that have to be signed by every member of the gold group, not issued with every block, just when needed when new gold is imported into the system.
Haven't we now got a gold trading system? All the advantages of bitcoin (save one*), and perfectly acceptable to the masses who don't like bitcoin but do like gold (like the fuddy-duddies on mises.org).
Want some gold? You buy it from one of these initial gold dealers, and they send that gold to your bitgold address. You can trade it with whomever you like, just as with bitcoins, and the gold traders aren't involved (other than running the bitgold miner nodes, and hence taking the transaction fees, so they are happy). When gold is removed from the system, it's a simple matter of deleting the address to which that gold has been moved (again, requiring trust).
I'm not actually advocating that we do this (although it would work). Haha! Tricked you. It's actually an argument for the fuddy-duddies. Here is the final step...
bitgold is so convenient and successful that nobody ever actually goes and claims their gold. Why would they? What if, at this moment, 99% of the gold vanished? Literally. It gets zapped by aliens. But... nobody knows that it's happened. Nobody need care. Trade is happening as it always has. Nobody actually wanted the gold (and for those that did, the 1% that's left will be fine).
Ignoring some minor differences about how the coins/gold was introduced to the chain, we've gotten to a point where bitgold is equivalent to bitcoins. Goldbugs of the world, and mises.org fuddy-duddies: where is your god now?
* We have to trust that the gold brokers really are honest. But people who like gold already have that problem. Very few gold bugs are actually buying physical gold, they are buying a promise of gold.
(I wasn't sure if this should be in economics; but I think the idea of bitgold is good enough on its own that it can go in disussion).
|
|
|
Rather than "unconfirmed"; which is a word that has meaning only to people who are familiar with bitcoin technology, how about doing this instead when displaying the balance in bitcoin clients: Cleared balance: 17.300 + uncleared deposits: 2.900 - uncleared withdrawals: 5.100 = Uncleared balance: 15.000
"Uncleared" is a much more familiar concept to mortals. Similarly transactions with zero confirmations would show as "uncleared". I'm not sure that I've picked the right way around though; it may be clearer for people to see this: Uncleared balance: 15.000 + uncleared withdrawals: 5.100 - uncleared deposits: 2.9 = cleared balance: 17.300
I think the uncleared balance is actually the important one (as we expect that to become the true balance), so it depends whether people think that should be at the top (maybe in a bigger font) or at the bottom.
|
|
|
I haven't got time to implement this idea; so I'm putting it here in case anyone is inspired.
Consider a new exchange. Let's have the following start conditions for their accounts (ignoring how we got to this point for now); and assume everyone is 100% honest.
User A has zero dollars and zero BTC. User B has 1000 dollars and zero BTC. User C has zero dollars and 100 BTC.
User C and user B trade as normal, with B buying 100 BTC for 1000 dollars.
Now, user B wants to withdraw 1000 dollars. Here's the trick: user A now wants to deposit 1000 dollars. The exchange tells user A to deposit to user B's bank account, rather than its own.
The exchange adjusts balances accordingly. User A has "deposited" 1000 dollars in the exchange, and user B has withdrawn 1000 dollars. Everyone has what they want.
Obviously this needs a lot of users to make it work; and it's unlikely that the figures would match up to make it work as smoothly. So... next step... the exchange runs a second currency exchange. Not BTC for dollars, but dollars-in-exchange-account for dollars-outside-exchange-account. If I happen to have $1000 in my checking account, I can "ask" 1001 inside-dollars for 1000 outside-dollars. Alternatively, I can "bid" 999 outside-dollars for 1000 inside-dollars.
The exchange then acts as an escrow and web-of-trust keeper rather than a centralised bank account.
Here's the even better bit... there is nothing to limit the currencies to dollars. People could offer 1600 inside-USD for 1000 outside-GBP.
It would also mean that the exchange was completely protected from the law; it has no bank accounts that can be seized.
|
|
|
http://www.geek.com/articles/mobile/google-pulls-emulators-from-the-android-market-20110530/Google continue their slide into being just as evil as every other gatekeeping corporation. Bitcoin has the potential to fix this problem though. Google are only necessary in the Android market because they take the money from the customer and distribute it to the developer. A bitcoin-based market would allow the user to connect directly to the developer. ... which in turn would stop this ridiculous behaviour of removing applications not because they are malicious but because some other corporation doesn't like it. (In this case it's emulators; next week it could easily be a Bitcoin wallet app).
|
|
|
Mt.Gox and MyBitcoin (at least) both seem to limit Bitcoin transfers to two decimal places.
I don't mean to 0.01; I mean that you can't send 100.009, you can only send 100.00.
Doesn't this create a Superman III opportunity for the site owners? As it's impossible to ever get the fractions of a cent out, they can aggregate them and do what they like with them.
I'm not saying they are doing this, but it shouldn't even be possible.
(edit: better title)
|
|
|
This is possibly a crazy idea; I won't let that stop me though.
At the moment, network difficulty is adjusted every two weeks. During that time, miners can enter or leave the game, making the hashing power of the network different from when it started. That means that unless the hashing power is static, it's almost impossible that blocks will ever be generated at the 1 per 10 minute target rate.
How about this as an alternative:
While miners are working, they publish their "best" block as they go. They monitor the network as well, and don't bother publishing a block that doesn't beat the current best. After ten minutes, the current best wins and all the miners start on the next block. The "best" block being the most difficult of course.
This would keep the block rate constant. Admittedly it would be a slightly increased bandwidth usage, but nothing too strenuous I think, as the publishing rate goes down exponentially as the "best" keeps being overridden.
|
|
|
Has anyone else thought that the blockchain technology could be used to run anonymous, verifiable, online votes?
Each citizen would be issued with a single VoteCoin. Then the election would be held by each person sending their vote to which ever candidate address they like.
Double votes would be impossible. Anyone who wanted to check their vote was correctly recorded could do so. The count would happen automatically. Anonymous voting is possible. Plausible deniability when pressured voting is a possibility is easily available (you just use block explorer and pick someone elses vote to announce).
I'd love to be able to vote like this.
|
|
|
|