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

They still represent an average difficulty to find one, which is why they are used as a standard unit in the probability calculations to start with.  Just because someone could get lucky and find a block on the first try doesn't mean that the odds of an attacker have improved, nor does it mean that the block represents just what work one node preforms to create the block.  It represents the, often unknown, average amount of work that the whole honest network must perform to produce a block.  The point that the percentages of hashing power still apply regardless of the block interval is true, for if an attacker can produce 51% of the hashing power of the network it doesn't matter what the target interval actually is.

2/3 second to found one
https://bitcointalksearch.org/topic/bitcointorrentzcom-torrent-download-service-42477

Heh no worry with the hijack - it is on topic but I was more just trying to get some comments relating to how Bitcoin is actually used also.
All the maths in the world will not make most people agree to waiting on average 50 minutes for a transaction to go through - which seems to be what happens at the moment - but no one seems to actually have an actual opinion on that either (other than calling it FUD)
I even asked before if anyone knows of any sites that accept 0 confirmations but no answer from anyone.
I certainly do not know any.

Who did you steal that staff flag on your account from ...

That quote is bullshit. You just removed the point of the quote for your own whatever stupid reasons you have.
Or did you not even bother to read ANY of the context?

The quote is:
I even posted again explaining what they meant.

Leave the thread and go get confused elsewhere.

I corrected the pros/cons comparison of faster blocks at:
https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
Credit goes to MeniRosenfeld and gmaxwell

kano: apologies for hijacking your thread with all the probability analysis, and regarding the main issues that concern you I (again) recommend that you give more thought to option 3 of having centralized hubs as a layer on top of bitcoin for inexpensive+instant transactions, also because of scalability issues discussed at https://en.bitcoin.it/wiki/Talk:Scalability

Example:
And you will continue to write those things to push your idea even if you are wrong.

What FUD?

Many are wasting time here, to me kano is just spreading FUD only to push his idea

Sorry - you misunderstood some of what I was saying ...

What I meant was exactly what I wrote - you require people to believe in 0 confirmation for POS to work with current bitcoin.
BUT people don't believe in it - they believe that they require 5 confirmations.
(I am also not arguing the validity of 0 confirmations - for or against)

Yes there are many sites that accept bitcoins - seriously I'm not sure why you made that statement at all.
I have never said to anyone that they can or cannot accept 0 confirmations.
I have simply made the very clear observation that few if none actually do accept 0 confirmations.

Again - I am not saying that they MUST accept 5 confirmations, I am simply observing that they ALL (or most) do want 5 confirmations.

OK I don't understand that statement at all.
Saving small pools will reduce the threat of large pools. Simple.
Reducing variance WILL help reduce the number of small pools that fail due to the current large variance (especially with regard to PPS)
Latency is already at X and we get Y collisions.
5Y collisions is not even an order of magnitude higher .........

You seem to have this issue with 0 confirmations.
All I can say is that you then need to convince all the people out there that trade with bitcoins that they should accept 0 confirmations.
I'm not trying to validate or repudiate 0 confirmations.
I'm simply looking at a way to deal with how Bitcoin works (and fails) NOW.

Here I think you are definitely wrong.
Again the reason why I made this thread is due to dealing with both BTC and LTC.
When I make LTC transactions I do watch and wait form them to complete at the target and then deal with the result ASAP.
With BTC transactions I just set and forget them and get back to them some time later in the future because they are too slow.
You may see no difference between an average 10 minutes and an average 50 minutes, but I can GUARANTEE that more than 90% of people would see the difference.
More so, consider adding variance onto 10 minutes vs adding variance onto 50 minutes.
The numbers make one hell of a big difference actually.
Not only that, people who accept BTC can reduce their acceptance to 2, 4, 6 etc minutes if they feel happy with fewer confirmations than 5 for smaller transactions.
At the moment they can't get below 10 minutes (though that is sometimes as high as 1 hour) without accepting 0 confirmations.
Yeah that may or may not be OK - but I am again talking about how BTC is use today, not someone's ideal of how it SHOULD be used.

It cripples nothing.
The actual transactions (on average) simply become spread across 5 x 10 BTC blocks instead of being only in 1 x 50 BTC block.
... and your last comment really says that the current BTC is no good with some number of orders of magnitude larger network.
I don't see that as a good reason for you wanting to turn people away from the current BTC.

Meaningless and inconsequential--blocks don't have inherent difficulties. If the pool operator gives me a block it could take me a billion hashes to find a solution--or I could get it on the first try. How long it takes is just dumb luck in choosing the right (or wrong) starting nonce.

The topic of workable instant POS solutions for bitcoin have been worked to death on this forum.  I've participated in many of those threads.  Is the search function, I'm not the one obligated to make the case that anything needs to change, nor that I'm wrong about the security model.  The math presented in this thread is incomplete, IMHO.  All a block is in this regard is a unit of measurable proof-of-work performed.  Just because such proof-of-work can be conveiently modeled around the unit, doesn't mean that the unit doesn't still represent the work that is done to create a block; and the work done is a continuous stream of proof-of-work.

As far as a POS system, there are a number of workable models that have been proposed by myself and others.  The most likely future solution, IMHO, is a side-channel network that allows bitcoin 'banks' such as more sophisticated online wallet services to securely communicate with each other in real time, verifying to each other that the client does have such a balance with much the same result as how an electronic check is processed today.  No, this would not be terriblely anonymous; but still more so than using a credit card for purchases today.  The vast majority of people don't need anoninimty in every little daily transaction anyway.

A drop to 2 minute block, 1 minute block or even 30 second block won't solve that.  No business is going to wait 2 minutes any more than they would 10 minutes.  Even at 30 second block that is simply too long and occasionally a 30 second block will result in multi-minute wait.  So shortening the block time solves nothing.


No one accepts bitcoins period (or close to no one).  Guess we should end bitcoin then right?  Maybe few merchants accept 0-confirms because people like you continually scream that they can't.


No they don't.  Examples have been provided.

Why does a monthly porn site need confirmations?
Why does an online video game need confirmations?
Why does an webhosting need confirmations?
Why does an online poker room need confirmations?
Why does a bitcoin lottery need confirmations?
Why does a mail order company need confirmations to begin processing the order?
Why does a password recovery service (hashing farm) need confirmations?
Why does a research site (yahoo answers) need confirmations?

Think about those examples and tell me what does the company lose on the few instances that they don't catch a double spend for say 5 minutes?  What does the attacker gain (remember there is still a 50% chance merchant is paid)

Some transactions require confirmations.  Transactions that are INSTANTANEOUS, HIGH VALUE AND IRREVOCABLE need confirmations.  An example would be an exchange, a registrar,



Don't try to save small pools, make it so large pools aren't a threat.  Technology like p2pool or even a traditional pool where block header creation is done at the miner level would eliminate the risk that large pools represent.  Even if you feel small pools are essential a small block time makes latency hugely important and a group of large pools could ensure they have less invalid blocks than small pools. Invalid blocks currently are rather rare but will occur much more frequently in a larger network and shorter block.  If anything short blocks may kill small pools once and for all.


Of course it is. Have you thought how you can complete a double spend.

You have two businesses A & B.  You create pair of double spend transactions A & B.
How will you ensure A sees transaction A and B sees transaction B but A doesn't see B and B doesn't see A.

Start thinking about it that way and you will realize countermeasures are rather easy. 
Can you name a single example of a 0-confirm double spend?

Reality: confirmations are not necessary for most transactions.   A drop in block time won't make confirmations noticeably faster and 1-confirm only provides additional protection against a single and very specific type of attack (Finney attack).

Except you fail to see it solves absolutely no problem while crippling the ability for Bitcoin to handle higher transaction volume.  The reality is that 10 minute blocks may be too small if Bitcoin network every became very large (hundreds of thousands or millions of nodes).

I do believe the discussion has gone a bit off target (IMO)

Simply because of a few things that I would love anyone to disprove (hopefully at least 2) is wrong):

1) Current bitcoin cannot be used as POS without 0 confirmation acceptance

2) No one accepts bitcoin transactions at 0 confirmations (or close enough to no one)

3) Most if not all online transaction processing requires at least 5 confirmations

Then again the added extra

4) Small pools are failing due to the high variance in block finding

Now yes it is useful to give arguments for or against changing the current functionality of Bitcoin, however, it does seem rather pointless to not provide a better solution that can be accepted ... since the problem exists and is not going away.

I would actually extend that to say: POS is not feasible with bitcoin without some other form of transaction validation added to it.
And really, that has nothing to do with what I'm suggesting here.

Reality: online bitcoin transaction are too slow.

My suggestion of a drop in difficulty (with a directly related drop in the value of a block) seems to be quite a feasable solution without dumping bitcoin as it stands ... and I will also add that adding some extra on top of bitcoin to deal with < 10sec confirmations seems more like hacking bitcoin into something else - rather than just creating a new 'something else'.

I am doing no such thing. Rather I am recognizing that the practical reality of the situation such that much of the costs of mounting an attack would be up-front/sunk costs (buying hardware, building a botnet, etc.), so much so that in any realistic scenario the difference in cost between simply preparing an attack and actually mounting it would be relatively quite small.

In the absence of a cloud-based burst-compute utility suitable for hash-computations at a scale to rival bitcoin and at a reasonable price (which doesn't, and likely will never exist), utility computation is a terrible model for the economics of attacking bitcoin.


1) such burst computing capacity does not exist
2) you're assuming the price-per-hash of utility compute will be comparable to the expenditures of your average bitcoin miner. in reality, it will be orders of magnitude more with something like AWS.
3) bitcoin needn't "consume a majority of all fungible computing power"--just a majority of the discretionary computing power/excess compute capacity. As stated that's a false argument, because...
4) you're ignoring the opportunity cost of that burst computing capacity. for small amounts of compute power this is zero. but once you exceed excess capacity you will be competing with existing users, driving up the price far in excess of actual costs.
5) if you can isolate a node, a 10 minute block interval won't provide much more protection than a X-second interval--.
6) network latency is 2.1 seconds today, with really very little optimizations. i expect average network latency for well connected nodes to go down, not up in the long term, but that is really a topic for a different thread.


And those are valid points which I agree with. Bitcoin should remain at 10 min block intervals, IMHO--but for these reasons, not because it offers any additional protection against hidden-adversary double-spend attacks (it doesn't).

This is a misleading description.  You're happily waving away the _cost_ of a particular attack.

Take bitcoin as it is.... if you'd like to buy computing time to mine a six block fork you should pay 300 BTC (plus some premium to get it all at once, I suppose). Under the 2.5/minute 12.5 BTC model, the cost would be 75.5 BTC.

(Before you protest that burst computing capacity in excess of bitcoin violates the security model— realize that is effectively an argument that honest bitcoin mining must consume a majority of all fungible computing power in the universe,  as compared to the far more limited requirement that the majority sustained hash power applied to bitcoin be honest.    It's also important to keep in mind that not all the attacks we guard against are races against the public network. It's pretty easy to isolate single nodes via sibyl attacks then slowly feed them blocks which have no chance of surviving on the main network)

The assumptions also require that blocks are not frequently found under the network latency. The 1s number being thrown around is nuts and obviously and observably not true today. Keep in mind that forwarding nodes also check the validity of the blocks before propagating them some of our larger recent blocks are hitting a second of validation (computation/disk IO) alone. This is why it takes several hours to syncup a new client now.

Then there is the point which I made in my first post which seems to have been ignored— part of why we _wait_ is not just to gain confirmations, but to reduce the risk that there was a network partition with considerable hash power on both sides.  E.g. If EU and the US lose internet connectivity people can spend on both sides. In order to be secure you must wait long enough that such a split is unlikely and/or long enough that if a split were to happen people would have an opportunity to detect it intervene (e.g. miners could stop processing new txn, sites could switch to higher confirmation limits— but only if they've detected the partition, which takes time if you are to avoid false positives).  Both criteria require absolute time, the distribution of blocks is irrelevant.

Perhaps I missed it, but I haven't really seen anyone address the point I made that this kind of change (10->2.5minutes) is a change in value but not in character. It doesn't suddenly make the system suitable for direct POS usage. There is a fairly narrow range of use cases where that would constitute an improvement and I suspect almost all of those uses could be adequately addressed by the solutions employed for POS processing.  (I assume everyone agrees that switching to _two second_ blocks needed for comfortable direct POS processing (keeping in mind the variance) most certainly would break it, even if you care to debate my arguments against decreases in general)   (Oh, I see maaku's edit now— oh well, this is worth repeating)

Show me, mathematically, why that is the case.

I have done the math (summarized earlier), and done simulations to verify this fact: as long as BLOCK_INTERVAL is significantly larger than NETWORK_LATENCY, one's chance of forcing a re-org to undo a transaction depends only on the number of confirmations and the percent of global hash power controlled.

So please, either bust out the math to show me where I'm wrong, or tell me how you're defining 'security'. Because from where I sit, breaking the security model means undoing a transaction, and the chance of doing that depends only on your relative hash rate and the number of confirmations.

But heck, don't take my word for it. Page 6 from Satoshi's whitepaper:


EDIT: For what it's worth, I agree with what has been posted earlier that decreasing the block interval yields little benefit unless you can get it down to single-digit seconds. 10 minutes remains a very good compromise. But nevertheless, decisions should be made on the facts.

That is one of the points I have already made of decreasing the block generation time which will decrease the block creation variance.
More smaller pools will be able to survive and not fail due to the current high variance in block creation.

However, related to another post, any discussion about increasing the number of LP's on the network is pointless.
This has already happened with merged mining and the factor is much higher than 5 times already - and who tried to stop it?
(well actually I did try )

Read the thread.

It's a great idea, 2min blocks = 10min to get 5 confirmations.
Result: 10 minute wait is so much better than 1 hour!!

But I have a better idea, 1min blocks = 5 min to get 5 confirmations.
5min is BETTER than 10min!!

I'm sure someone can top my idea shortly.