|
Puddinpop pool servers payout directly in that way.
|
|
|
|
How would look multitransaction with several entries of identical addresses with identical amounts? How they will be different for JSON client? The question is not idle, it is necessary for services like http://bitcoindarts.movoda.net/ but who can accept payments several times at the same address Two different transactions to the same address will have different txids (and possibly other info). |
|
|
|
|
Right now you have to delete the block database. It is possible for Bitcoin to re-scan the blocks. It doesn't look too difficult: loop through every block and run AddToWalletIfMine on each tx.
|
|
|
|
Is this a linear-time operation where you have to find all transactions that deposited money into that account before you can know the 'balance'?
Yes. Fortunately, only the owner of the address ever needs to do this. What can of performance hit could we expect once there are 1000's of transactions per block instead of just a half dozen or so? It's not that hard to scan through transactions, especially if you're not actually verifying the crypto for each one (which a lightweight client doesn't need to do). |
|
|
|
|
"sendfrom" doesn't actually send bitcoins from a particular address/account. It just reduces the account's balance after sending.
If you can send from a particular address, you could just send a pre-set number of bitcoins from the old owner to the new owner. The stock broker watches the block chain for transactions of a certain amount from the current owner, and whoever first receives coins of the proper amount from that address becomes the new owner.
|
|
|
|
3rd, the bitcoin client should be able to import 3rd party public keys. Allowing it to 'encrypt to address'. This could be very useful for sending private messages to people you trade with.
ECDSA doesn't support encryption. |
|
|
|
Theoretically they could manually fix it and give the bitcoins back, but I guess for this small amount it's not really worth it.
If I owned BSB, I wouldn't mind. Your claim doesn't take long to verify. |
|
|
|
I'm guessing the reason is that it's because they weren't transferred but were put in directly from generation using one of those pooled mining things.
Don't generate directly to site balances. The current version of bitcoind is incapable of detecting these transactions. There's nothing sites can do to fix it. |
|
|
|
is it possible to add those keys into another wallet? It's possible, but Bitcoin doesn't do it. A future version of Bitcoin might do it, though. In any case, it will be possible to manually extract keys from an old wallet and insert them into a new one. |
|
|
|
|
The public/private keys are in there, so it should always be possible to recover them, even if Bitcoin can't do it automatically.
|
|
|
|
Well, that's a massive investment, are we sure that doesn't tip over the balance of Bitcoin?
It will (for a while, at least). ArtForz will have 65% of the network. With this much CPU power, he could actually prevent all other blocks from making it into the chain. I don't think he will do this, though. Maybe pools are solution, because pool admin does not own processing power and no one entity can turn to monopoly. Still users own the power, they temporary
lend it to pool and can everytime connect to another entity when they don't like pool politics. Or can start mining back standalone.
Pool mining will still be unprofitable electricity-wise. They could be powered by volunteers, of course. |
|
|
|
Good idea. Bitcoin's network is weak, and you can do a lot of mischief if you can totally surround someone. The attack as you described it would be entirely possible if not for block timestamps. Difficulty is based on block timestamps, and blocks are rejected if their timestamps are too far from reality. An attacker attempting your attack would therefore have to match the difficulty progression of the real network in order to get a final timestamp that matches reality. If an attacker can do that, then they can overcome the real network. An attacker that is totally surrounding the bank can put it on a separate chain. The attacker will produce blocks slower than the real network, but the bank will accept them if those are the only blocks they see. This allows double-spending attacks against the bank, which may result in the bank accidentally becoming fractional-reserve. A later version of Bitcoin will probably produce a warning when it's receiving blocks more slowly that it should. In the future Bitcoin might support an ultra-lightweight mode that doesn't even download full blocks. This mode is clearly not meant for banks, but if the bank is running in this mode and surrounded, you can generate fake coins and make the bank take them. The bank can't verify the transactions for itself, so it relies on hash trees in the block chain. If the chain is bad, then even a transaction for 21 million BTC could be considered valid by such a client. See http://www.bitcoin.org/wiki/doku.php?id=weaknesses#cancer_nodesActually surrounding someone is difficult because Bitcoin will only make outbound connections to IPs on different /16 networks. Still, a bank would be wise to set -maxconnections=50 and connect to a couple of fallback nodes. |
|
|
|
|
ArtForz is planning on buying $200,000 in custom mining hardware. GPU mining will then become unprofitable for everyone. I don't know when he's going to do this (and it's not sure that he will), but I wouldn't risk buying a GPU for mining.
|
|
|
|
Hum... bitcoin tells me it's an invalid address. There must be a bug, but you get the idea, right ?
You need to use a 160-bit hash. SHA-1 or RIPEMD-160, for example. You could also truncate the SHA-256 hash to 160 bits -- this generally gives nearly as much security as using the entire hash. Ensure that you give /q/hashtoaddress exactly 40 hex characters in order to receive a valid address. For Bitcoin addresses, Bitcoin first does a SHA-256 hash and then does a RIPEMD-160 hash on the output. |
|
|
|
I desire attribution for my contributions. WTFPL, at least, seems to suggest that I would be OK with people plagiarizing, which I am not. Copyright should be abolished, of course, but I don't want to encourage people to take my work without attribution. There are probably legal problems with it. Compare it with the similar CC0 license: http://creativecommons.org/publicdomain/zero/1.0/legalcodeOne sentence is not going to cover all of the legal issues. Potentially someone could sue us for using our own stuff. WTFPL is less restrictive than CC-A, so legally copying material from the Bitcoin wiki would require you to get permission from all page authors. I prefer CC-A -- including a link back to the page is not a huge legal burden, and it clearly indicates that plagiarism is not acceptable. No one's going to sue anyone, anyway. I wouldn't mind CC0 or any of the more restrictive CC licenses. |
|
|
|
|
WTFPL is not an appropriate license, in any case. It would have the same legal problems as declaring that something is in the public domain. It is also incompatible with the CC-A license used on the Bitcoin wiki.
|
|
|
|
|
If a someone on Wikipedia uses oversight to remove your revision, I doubt any mirrors will go out of their way to keep your data alive.
|
|
|
|
|
Show Posts
