Topic: Suggested MAJOR change to Bitcoin - page 4. (Read 9442 times)

It makes me wonder: have any of the pool operators tried to implement long poll with Twitter?

I kinda understand their pain: how to implement a reliable multicast when seemingly the only tool available is a massive abuse of unicast?

Firstly, finally a response against the idea that isn't one of:
 1) Change is bad - don't change anything
and/or
 2) Everyone on the planet who deals with Bitcoin transactions does it wrong and no one is going to fix that

Meanwhile:
I don't really think a stupid response it relevant ...

... and ... my suggested change has no effect at all on the production rate of bitcoins or who should get them other than the people and pools that mine them.

Meanwhile I doubt the validity of some of what you have said based on LTC and how it already functions well in the real world.

Also:
I have already answered that by saying that if people want the same txn security they already have, then they simply wait for 5x the confirms - problem solved!

But again, change isn't bad by definition.

You are simply saying that the current value is correct and less security is incorrect.
Not what the difference actually is or why we must use the current value.

I usually mine multiple pools and have never seen two pools LP a minute apart (even when I was mining 5 pools at the same time back when there were major network problems and the big pools kept getting ddos'd)
2 minutes was chosen since it is above such problems and has shown in the real world to work well.

That additional advantage for large miners has not shown to exist in any scamcoin except at their start when the difficulty was well below what it should be.
(though I managed to make over 30BTC in the first 2 days of LTC with my low power CPU mining ...)

Um ... do any of these exist?

I'd say the opposite.
Can you give an example of why?
My example would be that the network has to deal with a small amount of extra data and thus a ddos attack is relatively somewhat less effective since the difference between normal and ddos is slightly less.

This is a perennially bad proposal.   The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time.   If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

A faster block time still is far too slow for "instant transactions" of the POS kind. So we have no less need for solutions for that, and when we have mature solutions for that then your whole concern is mostly moot.

Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers.  Requiring 4x the storage on mobile phones is not nice.

The increase block rate also increases exposure to DOS attacks marginally.

Finally, and perhaps most importantly:  Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

Actually I think it was doublec's exchange, so nothing to do with the %!$#%@$% SolidCoin 2.0

... wanders off to search for the post on the subject ... hmm it was i0coin and doublec's exchange ... still searching ...

Here: https://bitcointalksearch.org/topic/m.554140

We've had this discussion, and several like it, many times on this forum over the past two years.  I can assure you, the answer is no the target interval will not be changed.  For all the reasons already presented to you and others as well.

You are a "Hero" man,
I'll just give you that:
Confirmations are not relative to security,
it's only relative to respending.


For a respending , 10minutes waiting is affordable.

This would only work once, because it would be evident that such an event has occurred after the fact.  It would be fraud, and easily provable, and thus carries the same legal risks; and would immediately crash your "credit" with those affected vendors.  If this happens enough, those vendors will not accept bitcoin so easily without identifying information; but anonimity was never a certainty.  I have no anonimity with any of the vendors that I have traded with, it's just that no one else outside of the transaction has that data like is necessary with Paypal or Visa transactions.  Said another way, the transaction isn't tied to my identity in records except those that the vendor may keep.  Don't count on being anonymous to your vendors.

Merchant will need to learn to accept that.

1) You can simply pirate movies, books, games.  So the ideas that someone will use a Finney attack is somewhat dubious.  Far easier to just launch bittorrent.

2) Even IF the block time was 2 minutes is a paywall going to make user wait 2 minutes?  Really?  The tiny risk is simply not worth it.

3) There is always risk.  1+ confirms can be reversed with significant hashing power.  1000+ confirms can be reversed w/ 51% attack.  No CC transaction is risk free.  Digital goods certainly are more risk for CC than other forms.

I never said 0-confirms are risk free I said that the risk was overblown AND that changing the block time from 10 min to 2 min doesn't materially improve the situation.  Really the only attack vector it helps is against a Finney attack but even there it only helps for merchants who are willing to wait for 2 min block but not a 10 minute block.  Those waiting for 10 minute block are already "safe" and those unwilling to wait 2 min don't gain anything.

The reality is life has risk and rather than trying to develop some perfect ultra lock down system with 0.0000000000000000% risk it is better to simply design a system that mitigages risk.  If the fraud cost is 10% of that compared to CC then Bitcoin is a huge improvement.    The goal of a business should be to maximize profit (after fraud which is a cost of doing business) not trying to get fraud zero.

Once again: if the change was deemed beneficial, it wouldn't need to justify the breaking change all by itself but if we have this discussion now, we can potentially implement this once a breaking change is necessary for other reasons.

Well, that depends on what the paywall is for, but as a smallish solo miner I'd sure like to get a few songs/ebooks/games for free every month from every website that accepts 0 confirmation transactions. The combined incentive for an attacker might make this quite attractive! But then again, this would promote solo-mining which is probably a good thing for Bitcoin after all

The thing with websites and digital goods is that such an attack could be completely automated - the miner doesn't have to do anything, just make a small script that quickly buys all kinds of stuff before he issues a block that reverses the transaction. Sure, merchants could delay the acceptance to make it riskier for the attacker but I would be really careful before you suggest that there is absolutely no reason for such sites to require confirmations.

Your point is that double spending is largely a non issue - I think it is dangerous to start relying on that, simply because Bitcoin itself offers absolutely no guarantees for that. Once enough sites accept 0 confirmation transactions it will be exploited sooner or later! Such an incident might severely impact Bitcoin's reputation and I'd rather not see that happen.

Also pointing at the fact that it has not happened yet is a bit short-sighted IMHO, Bitcoin is still very little used. Just imagine you would know of a sure way to anonymously make an unlimited amount of small valued Paypal transactions...

This has nothing to do with whether we should change the block generation rate - automatically accepting 0 confirmation transactions at websites _is_ dangerous!

I acknowledge the fact that there exist ways to mitigate the risk, but please do not advertise 0 confirmation transactions as safe for automated websites before these are actually implemented, enabled by default and proven to work.

Not all attacks are the same and only 1 is prevented (somewhat) by a shorter block.

There are essentially 4 methods to defraud a block chain based currency:

1) "the 51% attack"  
This is the big one (and the method used to defraud the exchanges).  Start work on a block chain in private (the attack chain).  Exploit a irreversible transaction (like deposit to exchange, trade, withdraw in another currency).  Now include an alternate version in your attack chain.  When your attack chain is longer than the "legit chain" (which is inevitable if you have 51% of hashing power) broadcast your alternate chain.   The deposit to the exchange "disappears".  You keep the money and have equivalent value in an alternate currency.  Doubled your money and exchange loses the value of the deposit.  

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: FAIL (block will be reversed)
Waiting for 6+ confirms: FAIL (block will be reversed)
Ensuring no attacker has 51% of network:  PASS

2) The confirmed double spend.
With less than 51% hashing power you eventually will fall behind the legit chain (exact opposite of 51% attack).  However you may be able to reverse confirmations.  It requires some luck and significant fraction of hashing power (10% to 30%+).  The longer the confirmation chain the less likely you will be able to reverse the chain.  It is to prevent this attack (not 51% attack that we recommend 6+ confirms).  Satoshi paper does some analysis on how difficult it is to reverse transactions depending on how buried they are in the

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: FAIL (although still difficult as it requires massive hashing power)
Waiting for 6+ confirms: PASS (Increasingly improbable you can be defrauded as # of confirms increase)
Ensuring no attacker has 51% of network:  N/A

3) The Finney Attack
Attacker includes a transaction in a block he is mining (like transferring coins from himself to himself).  When he solves a block he spends those same coins in an alternate transaction and then publishes the block.  Since his transaction is already in the block it wins and the double spent merchant loses.   The opportunity for this attack is based on hashing power.  An attacker w/ 1% of global hashing power will have a 1% chance of pulling off the attack on each block.  This is the most "dangerous" of the attacks because it is theoretically plausible to pull off and will have no warning.  However it is unlikely it would be used on trivial purchases simply due to the cost.  Merchants need to evaluate if they are a potential target.  Those who aren't can accept 0-confirm transactions and those who are should wait for 1-confirm.

Countermeasures:
Actively looking for a double spend: FAIL (can't be detected)
Waiting for 1 confirmation: PASS (highly improbable attacker can get 2+ confirms)
Waiting for 6+ confirms: Not necessary but ultra cautious merchants could wait for 2+ confirms.
Ensuring no attacker has 51% of network:  N/A

3) The 0-confirm double spend
Attacker submits 2 transactions for same coins to the network.  If merchant is actively looking for double spends this is almost impossible to pull off.  Merchant could simply wait for transaction to arrive not from customer/attacker but from one of its remote peers (indicating transaction has propagated the network).  Merchant can make this more difficult by waiting for multiple confirmations and waiting say 60 seconds to see if any alternate transaction is seen.

Countermeasures:
Actively looking for a double spend: PASS (can be detected and avoided)
Waiting for 1 confirmation: Not necessary however merchants should evaluate the value of their goods & services
Waiting for 6+ confirms: Not necessary however merchants should evaluate the value of their goods & services
Ensuring no attacker has 51% of network:  N/A

So as you can see a shorter block really doesn't prevent any of the attack scenarios.  A 2 minute block isn't short enough to make real time confirmations and thus merchants will need to learn to defend against 0-confirm attacks.  A 2 minute block does prevent Finney attack but only if merchant is willing/able to wait 2+ minutes.  Very few transactions are vulnerable to this type of attack thus the value of making a breaking change seems inconclusive.

I think you might be thinking of the supernode being spoofed in Solidcoin, which was a different event.  Bitcoin doesn't use supernodes for this exact reason.

^^ More good thoughts from MoonShadow. 

If such a method exists, sure.  But once that method is known, there will be countermeasures.  The double-spend attack is defensible, even with zero confirms, if the vendor has good connectivity.


That's not true, it's just that the current client doesn't presently offer sidechannel checks.  For example, a vendor's client could accept a zero confirm transaction at face value with very little risk by doing the following...

1) check that the transactions presently have the funds according to the client's own copy of the blockchain (presently done)
2) send the transaction out to all of it's peers except one, and wait until it returns to itself via the final peer.  (not presently done)  

If the saved peer returns the transaction, or no double spends are discovered from this peer in ten seconds, then assume that the transaction is valid and give the guy his Big Mac.  If there is a double spend attack underway, then either the saved peer will return the transaction that your client sent, or another one.  If it sends another one, deny the purchause.  If it sends back your transaction, it doesn't likely matter that there could be another transaction out there, because your's dominates the network.  The finney attack alters the picture somewhat, but unless you're trying to sell a new car via a drive up window, the values justify the (small) risks of accepting that transaction.  If you are selling stuff online, you can accept the transaction tenatively; and cancel the shipment of goods if the transaction fails.  If you are selling something digital in nature, such as an mp3, simply use delayed redirection for the download to allow the above ten second checks to occur.

Well the double spend has happened on one of the exchanges with a scamcoin (not sure which one)
As I mentioned before the scamcoins have had their uses - one being to show actual attempts (and success) at attacking the network.

I agree.

As far as the original topic is concerned, I think I would be more likely to solo mine if there was 5 times the odds I'd find a block, even if the payout was smaller.  That might be good for the network to have more solo miners...

There are numerous reasons for not reducing the target interval, both present and future.  No network would be able to handle the propagation delays with a target of two minutes and a transaction volume anywhere near what Paypal processes on average.  There have been numerous threads in the past about how to process real time bitcoin transactions via channels external to the bitcoin network, as well as simply gauge the risks of accepting an unconfirmed transaction at face value for lower value transactions.

In short, no.

I saved your message
It should be added to the wiki

I think DeathAndTaxes has brought up some very good arguments as to why 0 confirmations is just fine to just about every transaction type.  I've always had a hunch that direction, but never bothered to do the research and figure out why.

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree that merchants should seriously look in to using 0-confirmation transactions.  It would help Bitcoin become more viable, and encourage people to use Bitcoins for purchases.

Even 80GH of stolen computational power has more value than $10 in stolen goods.