Topic: 0 confirmation - signed by miner? (Read 3501 times)

If you ask me, the reason - in part - that Bitcoin has been successful so far is that there are monetary incentives to keep the system running by the rules. If we start to depend on miners "doing the right thing" because we assume that they are concerned with the long-term survival of Bitcoin, I'm not sure things will continue to go well. Looking at the average human, it's hard for me to see that we are all that concerned with the long-term sustainability of important things that we depend on. I don't  think miners (being human beings) would be either.

This is an interesting discussion though. The 0-confirmation double spend problem would definitely be a valuable one to solve. I do think it would have to involve some form of centralization though. Not that this is necessarily a bad thing though, since no one would be forced to go this route.

Sweet you solved the 0-confirm double spend problem.  Strange nobody thought of that solution yet.


... or maybe it still isn't solved.  BTW a 0-confirm double spend is rather difficult to pull off but it isn't impossible.  You stating the difficulty of the attack isn't a solution.

Then the merchant should be able to see that they're being double-spent against and not give up the merchandise.

I think you forget that a double spend isn't "spend" wait ungodly amount of time then "double spend".
It is a near simultaneous release of two transactions. 

You are assuming the good transaction hits first.
What if the bad one does?
What if they hit at nearly the same time (most pools queue up transactions)?

No miners would voluntarily run a system that does this.  They may get higher fees, sure, but they make the system vulnerable to double spends by accepting later transactions to different destination addresses with higher fees.  By making the entire Bitcoin network vulnerable to double spends, they ensure that the higher fees they get are worth nothing.

A miner could use the fee in a "dependent transaction" to increase the speed at which the original transaction is included in a block, but would have to put constraints on rebroadcast transactions with higher fees.  Namely, the constraint would be that up to one output may have its value changed and up to one input may be added to increase transaction fee.  Otherwise, you open up double spends.

That would work however the attacker could do the same thing.  The double spend could contain a larger transaction fee and thus mining algorithm that is opportunistic would choose it for your transaction + transaction w/ fee sequence.

Given the "profit margin" for a double spend is potentially higher the attacker will always be able to "out-fee" a legit operator.

If miners (or at least large miners signed blocks w/ a private key then by looking at block signatures over the last say 7 days   would give you a decent estimate of hashing power.  Of course today no miner's do such a thing but if having X hashing power (that could be provable in realtime) was worth some economic value it would be relatively easy to implement.

With the current architecture, it's difficult to accept "instant" payments securely. It's unlikely that a merchant will individually have the infrastructure to check the propagation of a transaction so they can't even manage the risk of a double spend attack succeeding.

Someone with good (contractual?) relationships with the major mining pools could offer insurance at a rate probably around a small fraction of a percent of the transaction value. It's much easier for merchants and customers to account for a small constant insurance cost than large double-spend losses.

ByteCoin   

How to give a miner an incentive...

Let's say I'm a merchant.  I make a sale, and see the customer's transaction broadcast.  I want to ensure it gets into a block as quickly as possible.

I could (if the client allowed it) broadcast a new transaction based on that not-yet-confirmed transaction, with a fee.  Miners would then want to include the customer's transaction since that's the only way that my fee-paying transaction to them would be claimable.

That's perfect.  I love it.

It can also be the other way around. Miners publicly offer to "support" transactions which contain a minimum amount of fee.

I like where this is going. It seems a cheaper alternative to the "expensive green address" proposal I've seen before, and it is decentralized too.

I don't care for this twist myself.  Funding the insurance would be complicated.

Rather than getting dinged because some net split resulted in you signing off on the wrong half of a double-spend, I would prefer the motivation to be to get a reward for including the transaction as promised,




Offer an extra tx fee for a miner who includes the transaction in a block after making a signed promise.




The classic double-spend.  The miner can wait a few seconds before making the promise to ensure there are no conflicts; and the recipient can watch for it as well.  This will catch 90% of such attempts.

The rare exception will be where the network is severely split and the double-spender is able to exploit it to his advantage.  Someone selling a cup of coffee won't be worried about such cases, but a business subject to fraud - a wallet service for example - could simply wait until they has signed promises from 75% of the network before accepting the transaction.




Each time a miner signs a block they include a copy of a pubkey.  The merchant gets the last 1000 pubkeys from the blockchain.  If they want 75% of hashpower signing off, they wait until they have 750 signatures (or fewer: many of the blocks will have the same pubkey since most blocks are solved by a handful of pools; a pool which solved 150 of the last 100 blocks only needs to make the signed promise once).

It doesn't prove that it's approved by 75% of hashpower online right now, but 75% of the hashpower for the last 1000 blocks.

Pool operators can embed signatures in their blocks if they want.
It would be more complicated to organize such scheme on P2Pool though...

For example, a miner could send all generated coins to the same address and sign the tx with that address. Likely a more elegant way exists. If you mean you don't know if they'll have X hashing power in the future, yeah, of course.

And if this works out, it pretty much solves the tragedy of the commons scenario for transaction fees. People with interest in not having their transactions double spent could buy such form of insurance.
The question that stays in the air is whether the risk of suffering a double-spend is high enough to motivate people to buy such insurances. But I guess that the answer to that is that, if the risk is not the high, maybe there's not so much need for mining power either. Safer is not always better, you have to take the costs into account.

But how do you know something represents 40-50% of the hashpower? AFAIK, the only way of knowing is solving blocks.

If you take 1 BTC and create two transactions, both spending it to different addresses, then send out both transactions simultaneously to half your peers each, you could likely get two (or more, expand multi-spends to as many peers as you have) groups of mining peers on the network to promise to include each individual transaction in direct competition with each other as the announcements would arrive across the network at varying times.  As the spender, you are attempting multiple transactions at once and hoping that the recipients deem the number of promises they receive for their individual transaction to meet their threshold for trustworthiness.  As the recipient, this threshold would likely need to be a large majority of the network mining peers so as to ensure that even at the minimum number of possible double-spend transactions, two, you are reasonably sure that your transaction will be the one to be included in the block-chain first, thus preventing any duplicates from double-spending what you've received.

However I guess if the recipient client detects duplicate transactions on the network after a short given period of time (far less than waiting for a block to be found), destined for multiple different recipients, it could just default back to waiting for block confirmations.

Some miners still include zero fee txs today because it is not a bottleneck in their processing. When it becomes one you can be assured that only txs with fees that cover the cost of processing will be included. Similarly you can expect miners to voluntarily sign txs for you today at no cost. But in an anonymous system where you have no power to punish a signer who reneges, the signature is not worth anything. And even if it was, it will go away when miners become CPU bound. That's the way of the world.

Nope. The network is working just fine. If you could make 0-confirmation transactions safe (and this proposal won't) that would add value, but bitcoin certainly won't lose value without it.

none
what is the incentive today of miners to include transactions at all? the 0.1BTC transaction fees?
the incentive would be to keep the network working properly, otherwise bitcoins will lose their value.

But where's the incentive for a miner to do this? Perhaps it is cheap enough to do this today, but as the tx volume grows it quickly becomes a significant cost, both in terms of computation power and bandwidth. And what is the punishment if a miner signs a tx and then reneges and mines an alternate version (perhaps because it includes a larger tx fee?)