Bitcoin Forum
December 03, 2016, 05:52:44 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4]  All
  Print  
Author Topic: Best practice for fast transaction acceptance - how high is the risk?  (Read 21044 times)
wareen
Millionaire
Hero Member
*****
Offline Offline

Activity: 742

bitcoin-austria.at


View Profile
July 21, 2011, 12:09:50 AM
 #61

As long as T<R*(t/10), where T is the value of the transaction, R is the value of the block reward, and t is the time to conduct the transaction in minutes, a seller can safely accept payment at zero transactions. Just make sure that you measure T and R with the same units.
I think the problem here is, that there can potentially be much more than just one double-spent transaction. The incentive for the attacker comes from the combined gain from all duplicate transactions he manages to pull off from addresses he is going to publish within the delayed block - no?
Therefore a seller cannot safely accept payments at zero confirmations - even for very small payments.
1480787564
Hero Member
*
Offline Offline

Posts: 1480787564

View Profile Personal Message (Offline)

Ignore
1480787564
Reply with quote  #2

1480787564
Report to moderator
1480787564
Hero Member
*
Offline Offline

Posts: 1480787564

View Profile Personal Message (Offline)

Ignore
1480787564
Reply with quote  #2

1480787564
Report to moderator
There are several different types of Bitcoin clients. Hybrid server-assisted clients like Electrum get a lot of their network information from centralized servers, but they also check the server's results using blockchain header data. This is perhaps somewhat more secure than either server-assisted clients or header-only clients.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480787564
Hero Member
*
Offline Offline

Posts: 1480787564

View Profile Personal Message (Offline)

Ignore
1480787564
Reply with quote  #2

1480787564
Report to moderator
1480787564
Hero Member
*
Offline Offline

Posts: 1480787564

View Profile Personal Message (Offline)

Ignore
1480787564
Reply with quote  #2

1480787564
Report to moderator
molecular
Donator
Legendary
*
Offline Offline

Activity: 2128



View Profile
July 21, 2011, 05:31:44 AM
 #62

To cheat you, when he generates a block, he doesn't broadcast it. Instead, he runs down to your store...

I think the real danger is that a large mining operator would create a side business selling space in their blocks for these types of intentional double-spends.  When they generate a block they could send a text message to a bunch of people saying "try to spend NOW".

I wonder if there's some way to discourage that kind of anti-social behavior; could the network detect that was being done and "shun" that miner's blocks?


Well, it's detectable, no? The ripped-off merchants will complain and we will likely find out (at least if the operation is continued), which pool is the bad guy. (I'm assuming it will be a pool operator doing this side-business). People would leave the pool and therefore harm it, likely more substantially than can be made up through the side business. Therfore pool ops are unlikely to pull this off.

In case of a large solo-miner it's not so simple, because identifying the block source would be a lot harder, especially if he takes precautions (no?) and also because he doesn't suffer any harm from "people leaving the pool". In this case the only option might be to "shun" this miners blocks. Not so easy. The blocks might be detected by using a rogue customer using the "service" and looking for the specific transaction. Unfortunately, it would be easy to identify the rogue customer, because we'd need a way to broadcast this information and the bad guy could listen to that as well and simply block our rogue customer, right? Also there might be possibilities to abuse the system to harm competing miners.

While I can't think of a straightforward way to protect against this kind of anti-social behaviour, I also think this kind of behaviour is currenlty very unlikely to occur. This might change in the future, though.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
jav
Sr. Member
****
Offline Offline

Activity: 249


View Profile
July 21, 2011, 08:18:13 AM
 #63

As long as T<R*(t/10), where T is the value of the transaction, R is the value of the block reward, and t is the time to conduct the transaction in minutes, a seller can safely accept payment at zero transactions.

Note though, that the attacker - depending on the situation - might be able to use multiple small transactions to get around this. So you will need to limit this on a global level, rather than on a per-transaction level. This puts an upper limit on the number of zero-confirmation transactions you can accept in a given time span.

I also don't agree that it can be put in an easy formula like that. It depends on the situation and what kind of service or product is being sold. Especially if the attacker can try lots of times (maybe because it's very easy to refund the product that he bought when the attack wasn't successful), there are some realistic attacks to consider. More thoughts on this can be found in this thread: http://forum.bitcoin.org/index.php?topic=27417.msg347403#msg347403 .

Hive, a beautiful wallet with an app platform for Mac OS X, Android and Mobile Web. Translators wanted! iOS and OS X devs see BitcoinKit. Tweets @hivewallet. Donations appreciated at 1HLRg9C1GsfEVH555hgcjzDeas14jen2Cn.
buffett
Jr. Member
*
Offline Offline

Activity: 59


View Profile
December 06, 2014, 05:30:06 PM
 #64

I'm sorry for posting in a zombie thread. Anyone looking for a solution for accepting 0 confirmation payments may check blockcypher api: http://dev.blockcypher.com/reference.html#zero_confirmations

It's not mine but I think it's worth mention here since I was also struggling looking for a simple solution for this matter.
rackcityb1
Jr. Member
*
Offline Offline

Activity: 45


View Profile
December 07, 2014, 01:38:01 AM
 #65

I'm sorry for posting in a zombie thread. Anyone looking for a solution for accepting 0 confirmation payments may check blockcypher api: http://dev.blockcypher.com/reference.html#zero_confirmations

It's not mine but I think it's worth mention here since I was also struggling looking for a simple solution for this matter.
A better way would be to push the TX to the pools themselves.

Once you have a TX sent to you on your node (or you can view it on a block explorer), you have access to the raw, signed TX. You simply copy and paste the raw TX into a form that many pools have to have a particular TX included in the pools next block.

f2pool claims that any TX pushed via it's form will be given priority regardless of fee. (it is always a good practice to only accept a 0/unconfirmed TX if it included an appropriate fee)
Pages: « 1 2 3 [4]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!