"* The system includes the capability to add a tiny fee to any transaction for super-fast processing. However, almost all users consider the use of that feature unnecessary. And, it would normally be no more than US $0.01 Also, it is completely OPTIONAL, and always will be."
Is that technically accurate? Probably soon every transaction will require at least a 0.01 fee to clear in a reasonable time. |
|
|
|
Very nice explanation, Theymos. Can you comment on "max block size" in the future? Is it likely to stay the same for all time? If not how will it be increased?
It's a backward-incompatible change. Everyone needs to change at once or we'll have network fragmentation. Probably the increase will work like this: after it is determined with great certainty that the network actually can handle bigger blocks, Satoshi will set the larger size limit to take effect at some block number. If an overwhelming number of people accept this change, the generators will also have to change if they want their coins to remain valuable. It might also work in reverse, where almost all generators decide to reduce (or raise) the max block size. If clients want to have any real protection from double-spending, they also need to switch. The limit needs to increase at some point if Bitcoin is to become mainstream. 1MB is not an awful lot of transactions, so not increasing it would raise fees to unreasonable levels. |
|
|
|
|
There is a small cost to adding a new transaction. You have to store the transaction until it is spent, validate the transaction, and recompute part of the Merkle tree for the block. There will also be big network, disk, and electricity costs for generating blocks.
Block size limitations indicate that the network is unanimously willing and able to download, upload, and store blocks of that size every 10 minutes. It will probably stay at the current 1MB until Bitcoin has a solid backbone of generators. Then it can increase rapidly.
Some generators will set fees to the minimum, and some will set fees to the highest profitable level in the hope of raising it further. Most will be set somewhere in the middle. The generators will be saying, "We want to be paid on average this much," and the users will be saying, "We will pay only this much on average." This creates a really nice effect: your transaction will almost always clear eventually, but more fee = more speed.
The "minimum fee" for a generator will usually be the fee that causes the most fee-transactions to be included in the block. Volunteers or people who feel that the generation reward is enough might have a minimum fee of 0. This will happen less and less in the future, though, because costs will rise, inherent rewards will be reduced, and you'll therefore want to create blocks with at least some non-free transactions.
If the network overcharges, competitors will come in that claim the leftover transactions. If the network undercharges (a high-fee transaction exists, but it is not included in a block in favor of a cheaper one), competitors will come in with proper fee-based prioritization.
When the coins generated per block is low, users may not be willing to pay enough for generators to ever be profitable. Transactions will be really slow in this case, and the users will hopefully change their minds. If they don't, the least efficient generators will leave, the difficulty will be reduced, and generation will be profitable again. The users will be saying, "I'm not paying for that much CPU power! Reduce it."
|
|
|
|
In other words, there isn't any way to "claim" a coin without spending it, is there?
Right. An coin/output can be referenced/claimed/spent one time. |
|
|
|
|
I see a few options for learning about your transactions:
- Have the sender give you the transaction hash, and then use getdata
- Download (and then discard) all new blocks
- Use IP transactions (hopefully with some sort of authentication). Maybe using a built-in system like Tor's hidden services.
"Polltx" would be really bad for anonymity. Even people who are not paranoid would probably have a problem with the information divulged there.
|
|
|
|
Functionally, yes. But more than one address cannot "own" the same coins in the blockchain, because the blockchain only records settled transactions. A special transaction that could have multiple claims must remain outside of the blockchain until someone actually claims it, I believe.
No; it's possible to create a transaction with a script that allows claim by any listed transactions. This is valid and would be included in the block chain. There's even a special command in Bitcoin's scripting system that does this: OP_CHECKMULTISIG. |
|
|
|
Sounds like you would be trusting that the peer that sent you the relevant transactions to your new transaction to not be sending you a doctored set.
Not at all. The transactions form a hash tree, and the root of this tree is in the block header. The headers, of course, are verified through the Bitcoin proof-of-work block chain system. The attacker would have to break SHA-256 in order to give you fake transactions. Does the protocol permit a lightweight client to download a specific block from a random peer, or does it have to download them in order? Yes. You can also request specific transactions by hash, which would be useful in this scheme. If two lightweight clients are dealing with each other, they might want to rely on the network to provide the transactions required for the Merkle tree. |
|
|
|
|
I think Pecunix allows you to transfer 0.0001 GAU, so I would add another decimal of allowed precision when 0.01 BTC is worth more than 0.0001 GAU (pretty soon, if prices keep rising).
The decimal should be moved when transfers over 1 BTC are less than 1% of all real transactions. So probably not for a long time.
|
|
|
|
The advantage of balance sheets over lightweight clients is that lots of the block chain can be forgotten and there are not merkle tree stubs hanging around which are a non-trivial size.
Lightweight clients only need to store the parts of the Merkle trees that pertain to them. So if I am storing nothing but the block headers (no trees), someone sending me a Bitcoin transaction can send me the new transaction plus the required "branch transactions" in that block (usually not many extra transactions would be required). I can then reconstruct the Merkle root and verify the network's acceptance of the transaction without downloading a single entire Merkle tree. This relies on the network's verification ability only. Such a lightweight client would not be trusting anyone. Could you please explain what the real problem is? Balance sheets was intended to enable a fully featured mining-capable client while considerably reducing storage requirements. I believe that hard disk space will become a problem for average users long before network bandwidth or cpu usage. I don't care about the requirements for mining. The average person should not be mining. The sooner dedicated organizations are doing all the mining, the better. With the Bitcoin system, lightweight clients only need to download and store 80 bytes per block, plus temporarily a few extra transactions for every transaction they receive. Balance sheets requires storing and downloading a lot more data. |
|
|
|
I've just looked at Artforz scheme which is simpler than yours but my scheme is simpler still and looks like a normal transaction so is less likely to be speculatively brute-forced by an attacker. You say it's horribly insecure. How so?
I thought you wanted to brute-force a publicly-released private key and use that as the security. I read it wrong; sorry. Bitcoin private keys are much too large (279 bytes) to be typed in their entirety, so that wouldn't work, even if you could cut off ~2 bytes with brute-force. |
|
|
|
|
Problems with OP_BLOCKNUMBER might happen accidentally, whereas exploiting segmentation for double-spending is very difficult and requires someone to be attacking you.
|
|
|
|
|
Bitcoin already limits the size of debug.log.
|
|
|
|
Nice idea. Though, wouldn't it be more secure to use some SSL-supporting IRC network, instead of freenode?
Freenode supports encryption on ports 7070 and 7000. |
|
|
|
|
Create 101 new addresses and then send all of your coins to the 101st. Or sent all of your coins to a fresh installation of Bitcoin and then discard your old wallet.
|
|
|
|
There is an implied contract between the miners and the network that the effort that the miners exert to generate blocks is rewarded by 50BTC (at least, and at the moment) which they can spend as long as they take care not to lose their secret key for example. The network is breaking their side of the bargain by not allowing 50BTC rightfully mined to be spent.
The miners are mining wrong. You need to prevent this situation from happening. The network can't do it for you. |
|
|
|
so ... how did something like that even happen ?
Generation transactions aren't very different from one another if you modify Bitcoin to re-use the same key for every generation. The only real difference between them at this point is the extraNonce value, which has a relatively small range of typical values. This is not a fault in Bitcoin, but in someone's custom miner. (Maybe the network should have rejected the transaction. No harm done to the network, though.) |
|
|
|
Oh no! That's really bad!
Not really. The effect is limited to the people who create these transactions (which stock Bitcoin would never do). I probably should have specified in the OP: this is not a problem with the cryptography. These miners are actually creating transactions that are exactly the same. |
|
|
|
|
Show Posts
