Two hours is more what I'd like to see.
It's not safe to assume a transaction has been completely rejected after just 2 hours. Maybe it was just lost. You should wait at least a day or two. |
|
|
|
|
I don't think a new message is necessary. Bitcoin should allow you to unspend 0-confirmation transactions, sending a conflicting transaction back to itself. Maybe it can do this automatically after 2 weeks (or whatever), or immediately as soon as a double-spending transaction is confirmed in the block chain.
|
|
|
|
And you can only get a negative "" balance when you move coins from there to another account, right?
If that's the case then why is it only with the "" account?
Usually it happens when you send money without using sendfrom. The payment comes from "", and it only fails if the wallet as a whole has insufficient funds. OK, so the client moves addresses between accounts when you do a move?
No. It just changes the amount of BTC associated with that account in the database. You can move addresses with setaccount. |
|
|
|
1) It's possible to have a negative balance in an address. How is this possible? What's to stop me spending more bitcoins than I own?
It's not actually possible to have a negative balance. Any negative balances you see are UI quirks. AFAIK, only the "" account is supposed to be able to have a negative balance. 2) How does moving coins work? AFAIK, it's not a transaction.
The balances are just changed. No transaction stuff is done. |
|
|
|
|
I wouldn't. Bitcoin will certainly be replaced by something better at some point, even if it doesn't fail sooner.
|
|
|
|
So it would prob be a good idea to copy this file on a usb stick in case my computers crashes?
Yes. You should also update it every once in a while. Once per month is probably enough for most users. Make sure no one can access the USB stick, though, or they will be able to steal your bitcoins. |
|
|
|
When you (and the wiki) say "redeem", do you mean "use in another transaction"?
Yes. When you redeem a transaction output, you take its coins and use it in another transaction's inputs. Here's an example of a strange transaction without an automatically-detected address: http://blockexplorer.com/testnet/tx/64f85bece3a019f452121440b553132e13f6a0daab2664463c122b5e0682047bIn this case, it would be possible to find a valid address from the unusual public key (and if lots of people made these transactions, BBE would do so), but this doesn't always have to be the case. |
|
|
|
Can you explain further? I suppose generated coins don't have any sender addresses (looking at the wiki they lack a scriptSig), but regardless of whether a transfer has a recipient for all its input coins it will surely have to have at least one when it makes it into a block (i.e. the block generator).
Bitcoin supports a flexible transaction scripting system that could allow you to redeem a transaction without using public/private keys for authentication (using a password, for example). Then there would be no "from" address, as the funds would not have been sent using an address, but with some other method. |
|
|
|
Yeah, it was a problem with Bitcoin Block Explorer. Some blocks were not updated after a very large chain split (~8 blocks), which made the block chain wrong. The large split was detected: Tue, 12 Apr 2011 07:04:07 +0000
Starting block update: 13371 to 13377
BLOCK
Num: 13371$
Hash: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Prev: 00000000111f7c4035234f6406c97a2983188fb5d7eb99b3d3a36e8daf5faf8b$
Root: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Bits: 471724584$
Nonce: 762625496$
Timestamp: 1302591425$
Size: 215$
***Deleting conflicting block***INPUT
Type: Generation$
Value: 50$
Prev: $
TxHash: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Index: $
ScriptSig: 0428f21d1c0104$
Hash160: $
OUTPUT
Hash160: c418e6c01bd8a9956af410c68297b37c8d1acb02$
Type: Pubkey$
Index: 0$
Value: 50.00000000$
Scriptpubkey: 0446fa90919dfe5305beb9a741bbc05f2864a72692822c147eb8e754c8211af2e0
7f9d2b5974c72140313d3162721d5e9c0854820c28ac4c7ee3c485bbdae2e4e6 OP_CHECKSIG$
Total value: 50.00000000$
Transactions: 1$
Error: Updating blocks too far back BBE should have then turned itself off to prevent further damage. However, I haven't yet set up a system where only testnet can turn off, and previously testnet would take down mainnet, so I made testnet incapable of turning itself off. So it kept updating: Tue, 12 Apr 2011 07:06:07 +0000
Starting block update: 13371 to 13378
BLOCK
Num: 13371$
Hash: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Prev: 00000000111f7c4035234f6406c97a2983188fb5d7eb99b3d3a36e8daf5faf8b$
Root: 705d451e642b051ba98c132555ae84521436824b1dc68deb3e3fa4ae2f6d19d7$
Bits: 471724584$
Nonce: 762625496$
Timestamp: 1302591425$
Size: 215$
Already have this block
BLOCK
Num: 13372$
Hash: 00000000001212c841a0fe178666bb0f03cb16eda2d6cdc5917acbda01831f50$
Prev: 000000000c8b1c402c31fa803084aedf8b20d2f3f757bb3d6c47e42426516e2e$
Root: bf99ed83ed2f89f6e9d730f68c3f8d752f952422515e2a8c1daad2faf9551832$
Bits: 471724584$
Nonce: 2981433388$
Timestamp: 1302591435$
Size: 215$
***Deleting conflicting block***INPUT
Type: Generation$
Value: 50$
Prev: $
TxHash: bf99ed83ed2f89f6e9d730f68c3f8d752f952422515e2a8c1daad2faf9551832$
Index: $
ScriptSig: 0428f21d1c0108$
Hash160: $
OUTPUT
Hash160: a096f906cb7c73f5dabd57593ae7c3cc9ccae87b$
Type: Pubkey$
Index: 0$
Value: 50.00000000$
Scriptpubkey: 0480dad04b64362bd1217a5a812451963569e758c5084b2347aec9e1d85fc73b1d
e1f3f5bc784348a04f95b6b5afe6ac1438d06ce5e6b698fe39645fbb10c158ec OP_CHECKSIG$
... A few blocks before 13371 were then wrong, but the later blocks were still being updated. This resulted in a block containing transactions that had previously appeared in the now-orphan blocks. These appeared to be duplicates to BBE, but they actually weren't. The massive fee amount made me think it was a real exploit rather than just a BBE processing error, and this was corroborated by my analysis of BBE rawblock data, which was obviously also wrong. Testnet now looks back 10 blocks, which should make this more rare. I've also been planning a more elegant update control system that will allow testnet to turn itself off without taking down mainnet. |
|
|
|
Does this "dust change" situation still happen when the transaction is less than 0.01 bitcoins ?
It does. Another decimal of allowed precision might be added soon. |
|
|
|
Issue 2: I'm not entirely sure I've got the right picture on this one. There was a video on YouTube discussing BitCoin in general. There was a question about whether the data (blocks?) downloaded to each node about all transactions would take large amount of space. The answer was that only a few MB's would be needed, supposedy even when the number of transactions had grown to large amounts.
That's not implemented in the client yet, though the protocol supports it. |
|
|
|
I think, there is a need for fee pre-calculation API call. Like that: $ bitcoin feecalc 100.41318448
{
"txsize": 12.111,
"fee": 0.13
} Coins are randomized before selection, so that wouldn't be reliable. |
|
|
|
|
Thanks. That was the cause. I fixed the block.
Now I have to figure out how a reorg was missed...
|
|
|
|
|
Run Bitcoin with the -debug switch, double-click the transaction, and post the transaction dump here.
|
|
|
|
Also, if you run Bitcoin in debug mode and double click on a txn, it will give you a very short (16 char?) string which BlockExplorer knows what to do with. Theymos might be able to tell you what exactly that string is.
It's the first part the hash. Even with these few characters, collisions are rare. 50 characters is probably overkill. That's more entropy than even Bitcoin addresses. I'd probably use 12-16 bytes of high-quality randomness concatenated with the UTC time of item creation, leaving out the last four digits of the time. Then base58-encode this. It depends on the situation, though. |
|
|
|
You can always find out where the coins came from and send them back there again. Try putting an address in http://blockexplorer.com/Although I don't think the standard client provides any way to make sure you send back from the address you received on. Which you probably want to do unless you can prove the other addresses you use are related. It's not safe to refund in that way. |
|
|
|
Now we need someone to sell the pancakes to have with the maple syrup  Fresh maple syrup tastes really good on ice cream. I wouldn't even waste it on pancakes. |
|
|
|
Is there any way we can get a "go to first unread post" button as well? Or am I just missing it because I'm unfamiliar with the software?
I would definitely like that feature. I can't see it anywhere in the options. |
|
|
|
|
Show Posts
