I think it is a risk/reward thing.
Fees are <5% of the total reward at the moment. Increasing fees by 1% has almost no effect on the profitability of the pool.
If fees were 75% of the block reward, then they would make a much bigger difference.
Efficient tx selection is not that important at the moment. As tx fees increase relative to the mint reward, pools will start to advertise that they are better at picking transactions. Comparison sites could show how much the average fees per pool are.
If pools claim their blocks, then it would be easy to compare.
Topic: Double spending insurance (Read 1121 times)
Agreed. A pool that accepted double spends would quickly be shunned by the community.
Not sure if you're being sarcastic, but if not, you should have a look at this:https://bitcointalk.org/index.php?topic=327767.0 The pool that enabled the double spend (GHash.IO) basically even concedes that someone at their organization was involved in their official response.
So a pool has now accepted double spends with little to no consequences: https://blockchain.info/pools
If you were being sarcastic, then you probably already know all about this.
Agreed. A pool that accepted double spends would quickly be shunned by the community.
Not sure if you're being sarcastic, but if not, you should have a look at this:https://bitcointalk.org/index.php?topic=327767.0 The pool that enabled the double spend (GHash.IO) basically even concedes that someone at their organization was involved in their official response.
So a pool has now accepted double spends with little to no consequences: https://blockchain.info/pools
If you were being sarcastic, then you probably already know all about this.
Best insurance against double spending and netsplits: long block confirmation times.
You want the confirmation time to increase? Just making sure I understand you correctly ...
I meant many not long. Many block confirmations.
Aggh ... you had me worried for a bit there lol
Best insurance against double spending and netsplits: long block confirmation times.
You want the confirmation time to increase? Just making sure I understand you correctly ...
I meant many not long. Many block confirmations.
Best insurance against double spending and netsplits: long block confirmation times.
You want the confirmation time to increase? Just making sure I understand you correctly ...
Best insurance against double spending and netsplits: long block confirmation times.
Quote
A mining pool might decide to include them as a way to increase their average fees per block.
That would be quickly become knowledge and the mining pool would hopefully lose all their business very soon. With that logic an attacker could use a lot of fees to launch an attack successfully. Much above average fees would signal bad tx's immediately. A lot depends on the visibility of actions of miners. Which is why the supposed selfish mining attack was not considered really serious.
Agreed. A pool that accepted double spends would quickly be shunned by the community.
Quote
A mining pool might decide to include them as a way to increase their average fees per block.
That would be quickly become knowledge and the mining pool would hopefully lose all their business very soon. With that logic an attacker could use a lot of fees to launch an attack successfully. Much above average fees would signal bad tx's immediately. A lot depends on the visibility of actions of miners. Which is why the supposed selfish mining attack was not considered really serious.
From what I've read on other threads, the difficulty of pulling of a double spend is so great that its not even worth insuring against.
Double spend protection at the moment is based on 2 things. First, nodes will not propagate double spends. This makes it hard to get the double spending transaction to miners. Second, miners will not add double spends into their memory pools.
These are not inherent to bitcoin. There is nothing preventing a mining pool from accepting double spending transactions. If the double spending tx has a higher fee, then it is in the miner's best interests to include that instead of the original.
As the coinbase reward decreses, fees will become more significant. A mining pool might decide to include them as a way to increase their average fees per block.
Miners don't pick their pool on the basis of which has a higher average fee, since most pools do the job equally well and fees are not important.
If pools started signing their blocks to prove that they manage higher than average fees, then it pools that accept higher double spending fees would be at an advantage.
A pool with 0.5% higher payout on average is likely to get much more of the market. Small differences could be important.
ok gotcha.
From what I've read on other threads, the difficulty of pulling of a double spend is so great that its not even worth insuring against.
From what I've read on other threads, the difficulty of pulling of a double spend is so great that its not even worth insuring against.
The double spend "deposit" could be scaled with that probability. If only 5% of double spends succeed, then a merchant might demand a 10% double spend deposit.
The client has to pay double to start?
I was thinking about a protocol for protecting against double spending. It would require a new opcode via a soft fork.
OP_CHECK_DOUBLE
This marks the transaction as invalid unless txd double spends one of the inputs.
If it replaced a NOP, then it would be backwards compatible.
This allows a system similar to channels to support double spend protection.
Client creates public key (Kc)
Merchant creates public keys (Km1 and Km2)
Client creates payment transaction (P) which pays double the amount
Client creates refund transaction (R). It pays TX02 back to the the client but is time-locked 12 blocks in the future.
Client sends R to the Merchant
Merchant signs it with the private key for Km2 and sends back the signature.
Client verifies the signature, and sends P.
The merchant broadcasts P to the network. The merchant is now paid X.
12 blocks later the client spends the refund transaction to recover the deposit.
If the client successfully double spends the payment successfully, then P is cancelled, so the merchant gets nothing.
However, if the client attempts to double spend P, but fails, then the merchant gets double the amount.
If there is a 10% chance of a successful double spend, then double spending has a 90% chance of losing X and a 10% chance of gaining X. This makes it uneconomical to double spend.
The double spend "deposit" could be scaled with that probability. If only 5% of double spends succeed, then a merchant might demand a 10% double spend deposit.
OP_CHECK_DOUBLE would have to be accepted by > 50% of the miners like pay to script hash.
Maybe txd could be a digest of some kind, so that it doesn't get to large. For example, it might include internal states of the hashing function.
This marks the transaction as invalid unless txd double spends one of the inputs.
If it replaced a NOP, then it would be backwards compatible.
This allows a system similar to channels to support double spend protection.
Client creates public key (Kc)
Merchant creates public keys (Km1 and Km2)
Client creates payment transaction (P) which pays double the amount
Code:
TXO1(Pays X):
OP_DUP OP_HASH160OP_EQUALVERIFY OP_CHECKSIG
TXO2(Pays X):
OP_IF
22 CHECKMULTISIG
OP_ELSE
OP_CHECK_DOUBLEOP_CHECKSIG
OP_ENDIF
Client creates refund transaction (R). It pays TX02 back to the the client but is time-locked 12 blocks in the future.
Client sends R to the Merchant
Merchant signs it with the private key for Km2 and sends back the signature.
Client verifies the signature, and sends P.
The merchant broadcasts P to the network. The merchant is now paid X.
12 blocks later the client spends the refund transaction to recover the deposit.
If the client successfully double spends the payment successfully, then P is cancelled, so the merchant gets nothing.
However, if the client attempts to double spend P, but fails, then the merchant gets double the amount.
If there is a 10% chance of a successful double spend, then double spending has a 90% chance of losing X and a 10% chance of gaining X. This makes it uneconomical to double spend.
The double spend "deposit" could be scaled with that probability. If only 5% of double spends succeed, then a merchant might demand a 10% double spend deposit.
OP_CHECK_DOUBLE would have to be accepted by > 50% of the miners like pay to script hash.
Maybe txd could be a digest of some kind, so that it doesn't get to large. For example, it might include internal states of the hashing function.
Jump to: