First, bitcoin is deflative by design, its value will always rise against fiat money long term wise, thus people will always spend fiat money and save bitcoin if possible, resulting very little amount of bitcoin transactions being done for daily consumption
This speculation is factored into bitcoin's exchange rate. If, at a given exchange rate, both customers and merchants prefer holding bitcoin to holding fiat money then the rate will move. Second, besides Visa/Mastercard, some of the latest mobile payment network can already do instant transaction with almost zero fee. They use fiat money, thus have 100% domestic merchant support. Bitcoin does not have any fee/speed advantage against them, and the volatile exchange rate also makes it a bad currency for daily spending
Were bitcoin more widely accepted, it could compete very well with these networks for being more efficient. Merchants do not have to pay a fee to accept bitcoin transactions. |
|
|
|
Bitcoin has a stronger security story if you assume that there are many alturistic miners (or lazy parties and a total absense of economically rational developers to sell them better software).
This kind of pattern has been discussed many times in the past with varrious variations, includling things like pay to bury a double spend (with a chain of locked transactions paying high fees). Most of them right now only apply to fairly contrived cases involving mistaken fees, though as the subsidy goes down all fees end up high enough to trigger them.
Is it right to just assume the network is altruistic (or usefully lazy)? No -- if for no other reason than we've directly seen instances of miners intentionally act in ways to screw over users in order to make more profit. But I think it's also wrong to assume that it isn't alturistic at all. And at that point we start leaving the realm of what we can reason about formally and enter the realm of things that can only be judged by expirence and which are more vulnerable to chance. This doesn't frighten me-- even in the much stronger systems the real world always undermine your most critical assumptions.
I'm with you so far. No arguments here. That said, we should try to deliver something that has the best security properties under the weakest possible assumptions. The particular problem you've suggested here pretty much go away if transaction fees are mostly isotropic (which they would presumably be if transaction fees were efficiently allocated) and there is a standing backlog of transactions.
I'm curious. What does "isotropic" mean in this context? The harder case is the pay-for-reorg, and so far the best tool I've found to potentially improve that is the use of one-way-aggregatable signatures to make it computationally to extract a transaction that you only learned about from a block announcement and include it in your own block... but I think thats a fairly weak protection.
Interesting. Do you have a link to more on this? I've searched the forum and the web but all I've found so far is the "Increasing Anonymity in Bitcoin" paper. |
|
|
|
1) Bitcoin block rewards will eventually become infinitesimal, at that point transaction fees will be the only rewards miners get. Right now transaction fees are around 0.1-0.5 BTC per block, which is nowhere near enough funding to secure the network by itself. We need transaction fees to go up, and the only thing that will force them up is the blocksize limit. Increasing block size might cause fundamental damage to Bitcoin due to this.
(emphasis mine)Oft-cited, rarely questioned, and never satisfactorily argued. This is a myth. |
|
|
|
I guess this isn't going anywhere, though. I was looking for a way to solve the blocksize issue, but my idea hasn't had enough support so far. When I look at all the posts on this topic, there is clearly more people against the idea than there are supporters. Well, it was worth trying.
I appreciate the effort. |
|
|
|
Some people are afraid to "stick out of the crowd" too for fear of being called a pedo.
It's called well-socialized. Following the herd is life-affirming. Being a special snowflake & voicing your unique opinion is not. Such is lief  I guess that if child rape were legal and very popular that you would be strongly in favour of it. To have one's ethics completely dictated by social norms. Isn't that a kind of psychopathy? |
|
|
|
A cost of 25*N BTC does come into play if we're considering an extreme case: a 100% attack. In this scenario, the attacker rents all the hashing power in the world and sets it to work on his fork.
Of course - I had forgotten to consider hashing power... so if the attacker has less than 50% hashing power at his disposal, the cost of producing N blocks is exponential in N? If the attacker has less than 50% of the network's total hashing power then the probability that they will eventually catch up from N blocks behind falls exponentially with N. To find a suitable cost you'd have to specify the attacker's strategy in more detail. If, for example, the attacker never gives up, then their expected cost would be infinite for all N >= 1. |
|
|
|
Could you expand on this point for me please?
I meant pass the rest to OP_TRUE. This is an output that anyone is allowed to spend. It is effectively a gift to the miner of the next block, since why would the miners include someone else's transaction spending it, when they can spend it themselves. If the average fee per block was around 1BTC, but you include a transaction with 10BTC fee, then your coinbase gets 11BTC in fees. If you assign the entire 11BTC to yourself, then other miners might reject your block and create an alternative block. Another miner might create a block with 11BTC in fees, but pay 3 BTC to himself and 8 BTC to OP_TRUE. This means that anyone can spend the 8 BTC. The other miners have a choice, they can build on your block and just get the average of 1BTC or they can build on the other block and get part of the 8 BTC paid to OP_TRUE. If they decide to build on the 8 BTC OP_TRUE block they have to decide how much to take. They might decide to take only 1BTC, so they get 1BTC in fees plus 8 BTC from the OP_TRUE output and then pay 7 BTC to OP_TRUE. Some could also create a third block since they think that 2BTC out of the 10BTC was to much. Knowing how other miners will react is key to figuring out how much you should take of the payment to OP_TRUE. Thanks for the details. My blind spot was in not realising that a miner could process a transaction but then pass its fee onto the next miner. I assumed that a miner would only leave value in the mempool by abstaining from processing some transactions. Danny also caught me on this.  I appreciate that the problem is difficult but would appreciate any links you might have to attempts to take this further. If your example strategy: "take the average fee per block in fees, and pass the rest of OP_TRUE and break ties in favor of blocks which follow this rule"
works then it looks like a miner could choose, at no cost, whether to process some transactions and channel the fee to an OP_TRUE output or simply leave these same transactions in the mempool. In fact, they might realise a gain in the long term by intentionally leaving low-fee transactions on the table, signalling to users that 1-satoshi-fee transactions will occasionally be delayed. The classic tragedy-of-the-commons argument of a future with trivial fees would fall apart. A more careful analysis of this could be valuable in the block size limit debate as the popular BIP100 proposal appears to be partly motivated by the need for an artificial block size limit to create a fee market in the long term. I'm not convinced this strategy would be stable because it seems to rely on a widespread tie-breaker of "favor blocks which follow this rule" just as we currently rely on the widespread tie-breaker "favour blocks first seen". If the more profitable tie-breaker of "favour blocks which leave more on the table" becomes widespread then miners would have occasion to profit by undermining blocks built by small miners (basically no risk) while respecting similar blocks built by large miners. I'm sure we'd settle into some equilibrium but perhaps that equilibrium will only have one miner. |
|
|
|
Good point. While I don't think this works in this precise scenario because the miners cannot divide either of the 5 BTC sums,
- snip -
Sure they can. Just include both transactions in their block, take the fees, and create a transaction that will allow the next block to claim whatever portion of that 10 BTC they want to provide as incentive. D'oh! Of course. |
|
|
|
As TierNolan pointed out, predicting what all the rest of the hash power will do if there isn't an "attachment to an unprofitable default", is difficult. How many other miners are likely to ignore both Slush's and AntPool's blocks and try to create their own competing block? How many are going to remain with the "attachment to an unprofitable default", since they don't feel like they have enough hashpower to ever compete with the rest of the network? How many are trying to extend Slush's (they feel there's an advantage in mining on top of Slush's, but somehow don't see the advantage in competing with Slush's)? How many are concerned that if they mine on top of Slush's, that someone will repeat the process by mining a competing block to BitFury's?
Yes, it does seem to get complicated pretty quickly. I guess I'm interested in looking for equilibria, particularly equilibria where miners are co-operating in a fair 1 and efficient 2 manner. [1] A miner's reward is approximately proportional to its hashing power. [2] Most hashing power is employed to extend the longest chain. |
|
|
|
Keep in mind that if there is enough hash power that is taking advantage of the opportunity, then a significant amount of the hash power will NOT be building on top of Slush's block. Instead they'll be attempting to create another competing block of their own, and which keeps less than the 5 BTC that Sluch chose to keep. This will reduce the amount of mining power working on extending Slush's chain to the point where Slush will probably have to extend his own block before AntMiner extends his own. This process of everyone extending their own blocks will continue until a single chain is far enough ahead of all the others that the majority of hash power gives up and returns to "normal" operation.
Good point. While I don't think this works in this precise scenario because the miners cannot divide either of the 5 BTC sums, this could take place in a subsidy-less environment with many transactions (which is what I'm really studying here anyway). |
|
|
|
This is a concern as the minting fee reduces.
At the moment, a majority of the mining power mines on the earliest block seen. There is no reason why miners couldn't switch over to mining on the one that gives them the most profit.
If enough miners do that, then the optimal strategy shifts to leaving enough fees available so that other miners build on your block.
Ok, but this leaves me with some concerns. In particular, bigger mining entities are better able to defend their blocks and so may be able to take a larger chunk of the mempool with each of their blocks. Smaller pools may have to claim much less or risk being orphaned. This would give larger miners a quadratic advantage over smaller ones. Analysis is hard, since you have to assume what all the other miners are going to use as strategy.
I could see miners using a strategy of "take the average fee per block in fees, and pass the rest of OP_TRUE and break ties in favor of blocks which follow this rule".
(emphasis mine)Could you expand on this point for me please? |
|
|
|
In general most miners operate on a "first seen" block when they have two forks of the same length.
In order to make it worthwhile to take the risk for the extra 5 BTC, he's going to need to be pretty sure that at least 84% of the global hash power is all running software that will notice what he's done and will take advantage of it.
Interesting. So it seems that Slush's idea in the story is thwarted not by the financial incentives of other miners but by their attachment to an unprofitable default. Can we expect miners to continue to respect this "first seen" default in the long term? Is it important that they do so? |
|
|
|
Because you said that Slush thought Antpool was greedy. That means they started working after Antpool published their block. So Slush has one block to catch up... Unless you are saying that Slush predicted Antpool greed.
No, I'm not assuming any special predictive powers. What I'm looking for is some analysis of the supposed "lower odds" Slush must endure for competing with an existing block. What exactly is the risk of this one-block catch-up? Allow me to offer a simple analysis. Perhaps you can refine it: AntPool will try to extend its own block. Meanwhile, let's say all other miners work on Slush's block (because it's the more profitable chain for them). Slush's 30 BTC will be reasonably secure if and only if AntPool does not find the next block. This is in contrast to the default strategy where Slush builds on AntPool's block for 25 BTC, a sum that will be reasonably secure regardless of which miner finds the next block. If AntPool's share of the network's total hashrate is less than 5/30 (currently true: 13.7% < 16.7%) then the lower odds will have been more than compensated for by the extra reward. |
|
|
|
Sorry but why is Slush smarter? Its profit is 30 BTC with lower odds than if it had simply extended Antpool. Did it want to punish Antpool, if so - why even bother? I would understand if it took the 5 BTC fee and left behind a bit more than Antpool.
(emphasis mine)Could you explain exactly why Slush's odds were lower? Were the odds lowered enough to make it unwise to try for an extra 5 BTC? To clarify: Slush was only interested in profit in this story, not in punishing AntPool. |
|
|
|
The cost isn't really linear.
As Satoshi says, the chances of catching up becoming "vanishingly small", therefore the cost becomes exponentially large.
The cost of producing one block is roughly 25 BTC, the cost of producing N blocks is 25xN BTC - that looks linear in the number of blocks to me? Notice that the attacker will be claiming block rewards as he executes this attack. The rest of the network does not stand still while the attack is executed. The attacker may begin N blocks behind but it could take much more than N blocks to catch up. The expected cost is still linear in N but it is not 25*N BTC. A cost of 25*N BTC does come into play if we're considering an extreme case: a 100% attack. In this scenario, the attacker rents all the hashing power in the world and sets it to work on his fork. If the attacker has less hashing power than the rest of the network combined then he is guaranteed to stay behind in the long term and can only hope to get sufficiently lucky in the short term. This is the situation in which, as N increases, the probability of a successful attack becomes vanishingly small. |
|
|
|
Hypothetical:Two transactions are broadcast to the network, each with a whopping 5 BTC fee! After a few minutes, AntPool finds a block and includes both the transactions. Slush thinks that AntPool was greedy and begins to work on a parallel block. Slush finds a block before anyone extends AntPool's chain and he includes just one of the two transactions, leaving the other in the mempool. Discus Fish, BitFury, and KnCMiner all All other miners notice that AntPool's chain and Slush's chain have the same length and that they can get 5 BTC more by extending Slush's chain. Soon enough, BitFury extends Slush's chain and AntPool's block is orphaned.
---> AntPool (35 BTC) ---| (Orphan)
/
(Main chain) ---
\
---> Slush (30 BTC) ---> BitFury (30 BTC) ---> (Main chain)
Is this an attack? If so, who are the attackers? Was AntPool greedy? Was Slush clever or just lucky? Should a miner always prefer the longest chain? See also:
Edit:- Added information about the behaviours of other miners.
|
|
|
|
I kinda like your idea of 2 outputs with a "blank" one. A possible issue could be that it would not be doable with all clients. Much organization would be needed...
Yes, I was just trying to design a transaction that would be considered "standard" by the reference client. More exotic designs (such as having multiple OP_RETURN outputs) would be difficult to propogate. If you want it to be so that a vote can be cast easily by most/all clients then you have more of a challenge. Without some coin control, the voter would have no easy way to tie his wallets balance to a particular vote. This will basically be by design; good wallets protect the user's financial privacy by default. With coin control, a user might replace the OP_RETURN output with a regular transaction, burning a small number of satoshi to a special voting address. The number of satoshi burnt would correspond to the choice of the voter. Expect to meet resistance with such a proposal though as these voting outputs would not be "provably unspendable", tantamount to an attack on pruning nodes. I've just discovered that someone has already done what I've been thinking about. http://coin-vote.com/I don't like this way they do things, though. From their FAQ: How do I vote?
You first select your choice on a question, then press "Submit". You will be given a "Message to be signed", along with two empty fields. Go to your bitcoin wallet, choose an address that holds funds and use your wallet or bitcoin key to sign the message. You have to put the address (or TXID) which you used to make the signature in the first field on the coin-vote website, and the signature produced by your wallet in the second. Then, click submit. Your vote will be verified and counted. I'm not comfortable doing this. Why not? What is it that makes you uncomfortable? The main difference between this approach and ours is in whether the votes are store on-chain or off-chain. Another, more practical difference is in the wallet features needed to cast a vote (message signing/verification is more common than OP_RETURN support). |
|
|
|
I'm fairly certain this would necessitate difficulty perpetually increasing quadratically (and this would obviously break Bitcoin). Do you have some idea?
I was thinking along two different lines: *) having some kind of implicit difficulty instead of the explicit difficulty of solving a chain of blocks we have right now. so the head block has current network difficulty, and the next previous block has double the difficulty... somehow. *) having a different explicit linkage between blocks, such that the deeper down the chain you get, the more blocks you have re-hash. this probably requires a totally different blockchain structure tho. I think you ultimately have the problem that no matter how you restructure things, how some parts reference others, and how you weigh everything, it takes a certain amount of work to build the structure. The attacker would be able to build a competing structure for the same amount of work. Additionally, the attacker will have an information advantage because the elements of their structure will be built later in time and typically in private. |
|
|
|
|
"Necessity is the mother of invention" as they say.
Bitcoin is still in its experimental phase. Even the reference client states "This is experimental software." in its About window. The waters can be rough at times and nothing is certain. Those critically reliant on Bitcoin's smooth operation only have themselves to blame for their overexposure.
|
|
|
|
Perhaps Meni's elastic blocksize limit with rollover pools idea can be used for this.
Ah yes, that might do the trick. |
|
|
|
|
Show Posts
