|
We currently do double-sha256, not just sha256.
|
|
|
|
|
Have you added BTC payment methods yet?
I owe biddingpond.com a couple BTC for listings w/ buy now, but the site said something like
"Use one of the following payment methods to pay your account:"
[blank list, end of page]
|
|
|
|
|
I would prefer something like what is offered in stock trading: fixed fee commissions, regardless of number of shares traded.
For mtgox, an example of such pricing could be 1 BTC/trade or $0.25/trade.
|
|
|
|
|
Does the "-4way" switch do anything?
|
|
|
|
Mt Gox charges a small fee (0.65%) for each trade.
Yay! Good stuff. Exchanges need to be self-sustaining. |
|
|
|
I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline? I saw that the time for the adjustment was given as a block number and not as a date.
Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term. The transition is based on a wall-clock time span. It looks at the timestamp in each block. See GetNextWorkRequired() in main.cpp. Wait, are you saying reducing the coin per block award is not block number based? Yeah, you're right. My apologies, I thought the difficulty transition was being discussed, rather than the transition to 25 BTC blocks. |
|
|
|
I thought the transitions were based on the block number, not actually the number of weeks, so wouldn't this faster generation speed up the new timeline? I saw that the time for the adjustment was given as a block number and not as a date.
Yes, it is based on the block number. I was asking just to get an idea of how fast it has been going long term. The transition is based on a wall-clock time span. It looks at the timestamp in each block. See GetNextWorkRequired() in main.cpp. |
|
|
|
Is it just my connection or is BiddingPond down?
See the other biddingpond thread for their downtime announce. |
|
|
|
I agree that the Bitcoin coin generation should be a separate process that has a clean interface to the network.
I further think that the block chain maintainance code should be a separate process from the wallet management and transaction creating process.
Yes, there seems to be agreement that eventually users will have a "lightweight" bitcoin client to use, which can send/receive transactions, manage a wallet, and nothing more. This is analogous to the distinction between leaf nodes and ultrapeer nodes, on the Gnutella network. |
|
|
|
I guess a "distributed mining" option in the original client shut do the trick.
Just make a litle pop-up explaining what this is and why somebody would use it.
Then the average user can decide which way he want to generate coins.
+ 1, however this may be difficult to implement. Also, i don't like the idea of removing mining from Bitcoin completely. Perhaps it should use 10-25% of PC's computational power by default to make network stronger and more resistant to attacks. If user wants, he can shut down the block generation. Users do shut down bitcoin generation... after getting excited about mining, turning on generation, and then finding out they did nothing but generate a lot heat due to difficulty level. Mining is a small part, a beneficial side effect, of the overall bitcoin economy, with a very small, usually technically-skilled users excelling at mining and everyone else getting almost nothing. The most important thing is for users to be able to send and receive bitcoins in a decentralized manner. |
|
|
|
... teasing users with a "Generate coins?" option ... It's hard to get a new idea to take hold. The "generate coins" option is the hook that gets many people to download, install and run bitcoin. That's intentionally selling users a false premise, though, right? |
|
|
|
The difficulty is now so high that it might take a couple weeks for a beefy multi-core CPU to generate a single block. Therefore, I conclude that the existing CPU-based code in bitcoin is largely pointless, as GPU miners continue to win blocks. And GPU miners obviously require running a fork of bitcoin, rather than 100% upstream bitcoin. Therefore, it can be said that the overwhelming majority of today's generated blocks are generated by forked source code and not upstream bitcoin. Here's a radical proposal: - Move the current CPU miner code to a separate program, bitcoin-minerd.
- Listen on TCP port 8334 for incoming connections (w/ applicable IP address whitelist). When work arrives via P2P network, broadcast new work to all connected miners. Miners submit potential solutions via this same TCP connection.
This "remote mining" scheme with active TCP connections is superior to the polled 'getwork' method in use by some GPU miners. Incorporating remote mining into upstream will also provide a very strong incentive for GPU miner authors to use upstream bitcoin without modification (a win for open source, IMO). Moving CPU mining out of bitcoin, to a separate process, ends the current practice of teasing users with a "Generate coins?" option that will waste electricity for months on end, without generating any blocks, given the current difficulty level. That is not a friendly experience for first-time bitcoin.exe users. |
|
|
|
I noticed a bug in getblock (and bitcointools). Block 67300 is missing several transactions when compared to the output of Bitcoin's printblock, and the hash is also wrong.
I ran into the bug while parsing the entire chain: transaction e7a995 is spent in 67301, but according to getblock data that transaction was never made.
hmmmm. That's quite strange, considering the code simply loops over all 'vin' and 'vout', duplicating the code pattern used elsewhere to dump a block to the debug log. |
|
|
|
Price of BTC in USD up by a factor of approx. 15 to 25 in a few weeks. Yet the number of traders where you can spend Bitcoin on the internet has barely changed. This is beginning to look like a bubble.
I cannot disagree; however... any "serious" investor is going to have many thousands of USD$ at their disposal, if not millions. Bitcoin's entire market cap is only $1.2 million. Thus, the arrival of even a single "serious investor" seems likely to spark a huge price rally. |
|
|
|
mtgox software appears to be getting an update, including documentation of mtgox's automated trading API: http://mtgox.com/support/tradeAPII wouldn't do a lot of trading at the moment, but that's just me. |
|
|
|
I think ShadowOfHarbringer is alluding to the fact that if all the bitcoins were sold at once, it would depress the price below the current price, so that $1 million wouldn't actually be achieved.
Of course this is true. However, that is the standard definition of market cap elsewhere: share price times number of shares. Obviously, if everybody sold MSFT, their market cap would not be $229 billion. It's merely a snapshot of "right now" and nothing more. |
|
|
|
|
Bitcoin Watch creates an average USD/BTC price by looking at mtgox and bitcoinmarket, then multiplies the result by the number of bitcoins in existence.
|
|
|
|
|
With the right self-directed IRA, you can hold gold (at least, in ETF form).
|
|
|
|
For those who don't trade on margin, the existence of margin trading tends to exaggerate the peaks and troughs of the market. When prices are rising, it greatly increases the number of BTC that can be bought, causing the price to rise further. When prices are falling fast enough to force liquidations, it greatly increases the number of BTC that are being sold, which depresses the price further. I don't mind this, because it gives me more opportunity to buy very low and sell very high.
I think that's the rub: margin trading dramatically increases volatility. |
|
|
|
|
Show Posts
