I hate to keep mentioning this, but the network is already ready for the new fee. Even when I sent a transaction that wasn't relayed by the old version, it still made it into a block. No tricks used. The only explanation I have for this is that we also changed the channels for IRC bootstrapping at the same time, meaning most RC users have at least one connection to another RC user. http://blockexplorer.com/address/1ELvLsDRCaN8zSpZ8ZktAeM56tpfZ3E4kG |
|
|
|
Why a block every 10 minutes?
I'm sure this was discussed extensively when the protocol was first established and on this forum more than once, but I can't find anything on the reasoning.
On the surface, it seems to me if you are trying to create a global currency, then limiting any exchange of that currency to an average of once every 10 minutes seems like an artificial restriction on trade, and with some blocks I've seen a wait of over an hour until the the next.
I'm certain that it must have something to do with trust and preventing double-spending, but I would love to have that made more explicit. Network latency. Honestly, I heard that it was just an arbitrary number that they picked. What breaks if you aim for a block a minute and give the miner that found it 5 BTC instead of 50 for finding one, on average, every 10 minutes? Probably nothing. However, the only speeds that matter are <5 seconds and >5 seconds because that would be a reasonable amount of time for a person to wait when they are checking out at a grocery store, for example. Any longer and the speed doesn't matter as long as it's less than a day. Since the network latency for other big p2p projects are around 30 seconds, that's as low as we could go. Thus, 10 minutes provides the best trade-offs between latency, speed, bandwidth, and storage. Further reading: http://forum.bitcoin.org/index.php?topic=4382.msg67351#msg67351 |
|
|
|
|
Transaction completed successfully.
|
|
|
|
|
Thanks for doing this. I was planning on asking you to reduce the ticket price, but I couldn't figure out what to do about the tickets already purchased. That sounds like a fair solution.
|
|
|
|
My first test last night was successful. Broadcast through 38 nodes, a .0005 transaction was successfully blocked after 42 blocks. http://blockexplorer.com/address/1ELvLsDRCaN8zSpZ8ZktAeM56tpfZ3E4kGHonestly, if this is the worst case for a well-connected node when there are only, what, 100ish nodes on the RC, I think it could be pushed right out. |
|
|
|
10,356.22
+ 50.00
----------
10,406.22
10,406.22 + 50.00 ---------- 10,456.22 Not 100% sure, but looked like we lost a block probably due to default jgarzik's pool not retrying re-submiting work when bitcoind was unreachable... Oh well. Fortunately no one else was mining at that moment. It was a very short round too with just like 500 shares...  Lost blocks aren't truly lost. They are just not counted. Using a duplicate transaction hash in the generation transaction, though, WILL make them disappear. 11,456.22 - 50.00 ----------- 11,406.22 |
|
|
|
I'm thinking more of the network has already upgraded than you think. I did a few transactions that required fees today using the 0.0005 fee and they went through right away.
Most likely they were simply considered free transactions. Ah, I suppose with the amount of blocks found today there was more than enough room. I'll try a transaction under .01 BTC and see how long that takes. (if it even does take...) |
|
|
|
|
I'm thinking more of the network has already upgraded than you think. I did a few transactions that required fees today using the 0.0005 fee and they went through right away.
|
|
|
|
If you are curious, the displayed balance is the sum of the bitcoins in the block chain that have been assigned to keys that are in your wallet, and haven't been redeemed (assigned to another key). The node doesn't rescan the whole chain every time it starts, it keeps a running balance, and the id of the last block it read. If you grab the wallet files from a node that last saw block # 1000, and put those files on a node that has seen up to block # 2000, any transactions in nodes 1001 to 2000 that correspond to keys in your wallet won't be counted, and it will show you either too many coins, or too few.
As of 0.3.21, this issue has been mostly resolved. The client now saves the last block number in the wallet. When you start your client, it will re-scan the blocks between the last time the wallet was used and now. However, it is still not safe to run two clients at the same time, unless you're careful. You'll be fine as long as you wait one confirmation after your last spend and ensure that the blockchains are current on both clients. Further advances are being made to make this safer even in that shorter time-frame. In a future version, double-spends will be detected and reversed, making it impossible to actually lose bitcoins by sharing a wallet between clients. However, it should still be avoided. |
|
|
|
A guy once lost 9.000 BTC by restoring a backup produced before a send transaction which had these 9.000 as input. That motivated Satoshi to implement the pool of addresses feature. EDIT: Here's the topic: http://bitcointalk.org/index.php?topic=782.0Looking back at that, he still had 1 btc. So... 9300.22 - 1.00 ---------- 9299.22 |
|
|
|
I remember reading that MT Gox was working on enabling direct deposits to and from US bank accounts. Is that still going to happen or was I mistaken?
I suspect that Dwolla usurped the need for that. Once you set it up, it's no slower than MtGox would be able to do directly. Not to mention, $0.25 each way is pretty cheap. |
|
|
|
We've known for a while it works. My question is, who's responsibility is it to trying prevent this? Pool operators obviously don't have a big interest in keeping out computing power and I can't blame them. Though if it's just a matter of way the pool is being operated then, who else can? Soloing is an option, but not a great option for everyone. And lastly, is this really an issue that exist and can we detect this in any way with proof? The talks of it being possible has been around for a long time now.
You can probably detect it statistically from the distribution of block times for the pool. If there is pool hopping then there should be a longer tail. In the extreme case (which obviously doesn't happen) once a block takes too long everyone hops out and the block never finishes (infinite block time). I don't know for sure there is enough data to make a strong statistical inference on this, but I would guess there is. I would bet every BTC I own that there is pool hopping happening on at a fairly large scale, and people have automated it. And I agree that the way things are structured now the pools don't have a huge incentive to do anything about it. The best thing to do is avoid pools without good defenses. You can do more than just detect it. When Slush was planning on changing to score-based as a result of the paper, the comparison between share and score based pooling specifically showed three people who were pool-hopping. And this was a while ago. |
|
|
|
I just sent in my guess. It will make some of you choke on your drink.
$17? Makes sense with the current increase we've seen. I'll add $14.80 for 0.148. |
|
|
|
|
Works in Firefox if you override the security block.
Set network.websocket.override-security-block to true in about:config
DO NOT ENABLE THIS IF YOU ARE BEHIND A PROXY
|
|
|
|
|
I'll kick things off...
I bet 0.097 btc that the price will be $9.70. Yeah, it's a small bet, but that's still a month out.
It's coming from 1NptwUa4wFNUXPyhQ8wsS54s36QeTPaJYK
|
|
|
|
|
Oh, nice!
Interesting that you chose that address out of the four inputs, since that's what I used in the first version of your lottery!
+rep!
|
|
|
|
It can always verify the HTTP download with other peers afterwards, so it wouldn't be any more insecure.
Actually, the act of downloading the blockchain is quite fast. In fact, it's the verification part that takes the longest. This will be easier once we have "light" clients. They can start in "light" mode and convert to a full node over time. |
|
|
|
Ok, now the service provider is honest but the thief is very clever and waits for that window between you giving the key to the service provider and them running the transaction
How would a thief know when you give the service your key? |
|
|
|
|
Show Posts
