Collaboration between pools could make accepting 0-confirmation transaction safe

[Serith]

Alright, consider next scenario:
A buyer wants to execute bitcoin transaction and have a product released couple seconds after pressing Ok. A seller constructs multi-signature transaction that has to be signed by buyer and several major pools, so there would be more then 50% of hashing power behind that transaction.
By signing the transaction a pool gives it's trustworthy word that in case everyone else listed would sign the transaction then there will be a version of blockchain where this transaction has predetermined number of confirmations, e.g. 6. The transaction should also include small fee to every pool, so it would worth for an operator to establish relationships with other pools to ensure that everyone follows the rules, although the total fee suppose to be lower then 0.75%-0.4% fee of ZipConf.

This targets to remove the threat of Finney attack, which can't be detected just by listening to Bitcoin network for a conflicting transaction. To execute the attack an attacker has to have longer blockchain for a short period of time, but hides it until a malicious transaction executed and only then broadcasts the blockchain making the transaction orphan.

Cons: this gives power to the pools to arbitrary reject a valid block and continue to mine on shorter blockchain, would it be possible to abuse it despite that the whole process is transparent?

[gmaxwell]

Alright, consider next scenario:
A buyer wants to execute bitcoin transaction and have a product released couple seconds after pressing Ok. A seller constructs multi-signature transaction that has to be signed by buyer and several major pools, so there would be more then 50% of hashing power behind that transaction.

I pay you normally without using this system, then use the pool-signed txn to pay myself in a doublespend.  It would make attacks very reliable.

Besides, if your idea is predicated on large centralized pools I wouldn't count on it remaining viable. They're bad for the decentralization of bitcoin and present single points of failure. With the rise of asic mining making miners with single GPUs insignificant I expect to see mining move towards decentralized pooling techniques like p2pool, or the eligius memorypool mode.

[Realpra]

I pay you normally without using this system, then use the pool-signed txn to pay myself in a doublespend.  It would make attacks very reliable.

Nice, didn't see that!

I'm not too worried about double spends; the time frame you have to run away with your product, the loops you have to jump through and the small amounts people will only accept with 0 confs... just not worth it.

[Serith]

I pay you normally without using this system, then use the pool-signed txn to pay myself in a doublespend.  It would make attacks very reliable.

A pool must check if there is any conflicting transaction already present and if true then refuse to sign the multi-signature transaction.

Besides, if your idea is predicated on large centralized pools I wouldn't count on it remaining viable. They're bad for the decentralization of bitcoin and present single points of failure. With the rise of asic mining making miners with single GPUs insignificant I expect to see mining move towards decentralized pooling techniques like p2pool, or the eligius memorypool mode.

It may still work even if hundreds of pools and miners are required to sign the transaction. The limiting factors are size of the transaction and subsequent transaction fee, complexity of maintaining trust relationships between participating pools and heavy miners, turnaround time to get transaction signed by all participants.

[caveden]

OP, in what is that better than Green Addresses?
In both models there's trust in a third party, and Green Addresses are probably cheaper (so far they're free, aren't them?)

With the rise of asic mining making miners with single GPUs insignificant I expect to see mining move towards decentralized pooling techniques like p2pool, or the eligius memorypool mode.

P2Pool AFAIK requires the miner to have a full client. That's not scalable.
I don't know about this memorypool you talk about though.

[Serith]

I'm not too worried about double spends; the time frame you have to run away with your product, the loops you have to jump through and the small amounts people will only accept with 0 confs... just not worth it.

Sure, you can't execute Finney attack for in store purchase, but for over internet purchase that's not a problem, just wait until you found a block then automatically run a script that makes purchase on a website that accepts 0-confirmation transaction, and after transaction complete realize the block. I think insecurity of 0-confirmation transaction is the reason why there is so few places that accept it.

OP, in what is that better than Green Addresses?
In both models there's trust in a third party, and Green Addresses are probably cheaper (so far they're free, aren't them?)

Green Address model requires trust relationship between every merchant using it and a Green Address operator, and it's not scalable because too many Green Addresses from different operators would require from a merchant to maintain a list of trusted entities.
Unlike what I described that requires trust relationships between fixed number of people. Only pool operators would have to collaborate to make it work, and a merchant would only need to trust to single entity that consists from fixed number of pool operators, also it wouldn't require any additional code on a merchant side in order to start accepting 0-confirmation transactions.

[Realpra]

I'm not too worried about double spends; the time frame you have to run away with your product, the loops you have to jump through and the small amounts people will only accept with 0 confs... just not worth it.

Sure, you can't execute Finney attack for in store purchase, but for over internet purchase that's not a problem

Except its pretty easy as a website delaying anything significant (sending money/products) say 10 minutes. That pretty much destroys any double spend attack I have heard of.

Sure you could steal a micro-payment unlocked article that I would unlock with 0-conf. but then after 10 minutes I would ban your IP forever/call the cops and have lost a total of 0.01 BTC.

[caveden]

Sure you could steal a micro-payment unlocked article that I would unlock with 0-conf. but then after 10 minutes I would ban your IP forever/call the cops and have lost a total of 0.01 BTC.

Banning IP and calling the cops is useless.
Of course, for a 0,01BTC tx the damage would be so trivial that the risk is also trivial, you can pretty much take it.

There are some use cases where 0-conf would be interesting and the damage caused by a double-spend would not be that trivial though. Take cash ATMs for instance. It would be annoying to wait for confirmation, but the ATM cannot risk a double-spend when giving cash away. Or imagine an ATM like this one: https://en.wikipedia.org/wiki/Gold_to_Go

[Realpra]

ATMs have cameras and since cash is involved I am pretty sure you could in fact call the cops with some success.

The ATM might also say require your fingerprint, just in case!

Would YOU risk robbing an ATM with max 10 min. of a head start from the cops?

If your attack is detected make that head start smaller.


Even should you succeed you likely would get a maximum of 10k$, trivial compared to bitcoinicas loss and considering the expertise the thieves would have to posses. + your fingerprints are now on police file.

[wabber]

About the con that you mentioned:

If 50% of the network know about your contract and a solominer that doesn't mines on the longest chain, then he's wasting his work because all the major pools are still working on an older block.
So with your proposal you are bribing the major pools to work against the rest of the network if there's a double spend to your transaction. That doesn't sound like a good thing and it also decreases the income of the normal miners and lowers the overall security of the network.

[caveden]

ATMs have cameras and since cash is involved I am pretty sure you could in fact call the cops with some success.

The ATM might also say require your fingerprint, just in case!

Would YOU risk robbing an ATM with max 10. of a head start from the cops?

Well, in my country, robbers blow ATMs up with dynamite, get as much untainted cash as they manage to, and run away, all that in less than 2 min. AFAIK most of the time they're not caught.

So, yeah, you'd better protect yourself against double-spending!

[caveden]

About the con that you mentioned:
So with your proposal you are bribing the major pools to work against the rest of the network if there's a double spend to your transaction. That doesn't sound like a good thing and it also decreases the income of the normal miners and lowers the overall security of the network.

It's not really "working against the rest of the network". If they're really honest miners, they'll just replace the double-spend they're being payed to avoid. They can pretty well replicate all other honest transactions. At most there'll be a "blip" in the confirmation count of others.

[FreeMoney]

ATMs have cameras and since cash is involved I am pretty sure you could in fact call the cops with some success.

The ATM might also say require your fingerprint, just in case!

Would YOU risk robbing an ATM with max 10. of a head start from the cops?

If your attack is detected make that head start smaller.


Even should you succeed you likely would get a maximum of 10k$, trivial compared to bitcoinicas loss and considering the expertise the thieves would have to posses. + your fingerprints are now on police file.

Lol, thief can engineer a double spend, but not wear gloves. Lucky for us!

[wabber]

It's not really "working against the rest of the network".

Hm I think it is. Let's say i pay the biggest pools to not accept double spends of my transaction. Then I create a block including the double spend and broadcast it. That will result in a network split were the miners i've paid are still mining on the old block and the miners i didn't pay will work on the new block because its a legal block.

I suppose the fee for such a guaranteed transaction shouldn't be too much which means that it's pretty cheap to split the network (well you still need some mining power but around 100Gh/s should be enough to cause one split a day)

[caveden]

Splits happen from time to time, that's not working against the network. Plus, why would you generate a block and pay the majority of the miners to overrun it? You'd be throwing away all the reward of the block by doing so.

[Serith]

About the con that you mentioned:

If 50% of the network know about your contract and a solominer that doesn't mines on the longest chain, then he's wasting his work because all the major pools are still working on an older block.
So with your proposal you are bribing the major pools to work against the rest of the network if there's a double spend to your transaction. That doesn't sound like a good thing and it also decreases the income of the normal miners and lowers the overall security of the network.

That scenario would be extremely rare (only when someone makes a costly mistake) because it would be pointless to try to execute Finney attack and would make an attacker to only loose money by throwing away a good block in case he tries.

Hm I think it is. Let's say i pay the biggest pools to not accept double spends of my transaction. Then I create a block including the double spend and broadcast it. That will result in a network split were the miners i've paid are still mining on the old block and the miners i didn't pay will work on the new block because its a legal block.

I suppose the fee for such a guaranteed transaction shouldn't be too much which means that it's pretty cheap to split the network (well you still need some mining power but around 100Gh/s should be enough to cause one split a day)

Besides the fees you would also loose money from the valid block that you found. I did a quick math on that and in the end that strategy would make an attacker to pay more then the damage he made to solo miners.

[Realpra]

Well, in my country, robbers blow ATMs up with dynamite, get as much untainted cash as they manage to, and run away, all that in less than 2 min. AFAIK most of the time they're not caught.

So, yeah, you'd better protect yourself against double-spending!

Lol what the hell kind of country is that!

Lol, thief can engineer a double spend, but not wear gloves. Lucky for us!

I'm pretty sure print scanners today can tell if you are showing a print or nothing.


Anyway I'm not saying its impossible just that double-spends aren't that potent, maybe except for ATMs. (Which apparently are dynamited anyway)

[MatthewLM]

Well, in my country, robbers blow ATMs up with dynamite, get as much untainted cash as they manage to, and run away, all that in less than 2 min. AFAIK most of the time they're not caught.

So, yeah, you'd better protect yourself against double-spending!

Lol what the hell kind of country is that!

A country I want to live in!

[wabber]

Splits happen from time to time, that's not working against the network. Plus, why would you generate a block and pay the majority of the miners to overrun it? You'd be throwing away all the reward of the block by doing so.

But this split can go on for days. If I pay 50% of the miners and then release my double spend block the split will continue until the miners I paid build a longer chain because they will never accept the chain of the other miners who included my block.
By paying nodes not to include certain blocks we change their valid block policy you can't compare that to todays splits which are caused by block propagation lag.

[Serith]

Splits happen from time to time, that's not working against the network. Plus, why would you generate a block and pay the majority of the miners to overrun it? You'd be throwing away all the reward of the block by doing so.

But this split can go on for days. If I pay 50% of the miners and then release my double spend block the split will continue until the miners I paid build a longer chain because they will never accept the chain of the other miners who included my block.
By paying nodes not to include certain blocks we change their valid block policy you can't compare that to todays splits which are caused by block propagation lag.

There is couple ways to counter that, the most obvious is that every miner knows about pool-signed tnx, so everyone can make intelligent decision not to mine on chain that eventually would become orphan. Second, a pool can require that there must be at least 60%-70% percent behind the transaction in order to get signed by the pool.