You are viewing a single comment's thread from:
RE: What I think makes Bitcoin Bitcoin, and why I think Bitcoin Cash is Bitcoin
I'm asking you what SL layer meant you use same acronym again.
Sure BCH relies on the "good behaviour" of miners, but they want to profit and that's why they do it. It's not supposed to be normal for it to be the other way around.
So does the miner on the BTC chain (even more), The difference is that there aren't technically illiterate idiots who claiming the transaction is safe on the BTC side.
why do you bring this up?
The choice is yours.
Yeah, Whatever!
Not quite. Not during rush hour, when the upwards bidding war ensues. And don't get me wrong, a "fee market" already existed. It's good that there is one. But it was never intended to push the minimum fees up.
It's interesting that you would note that "technically illiterate idiots" don't exist on the other side. How was this accomplished if you don't mind?
The Bitcoin Cash developer teams know full well that a confirmed transaction is safer. That's not the point. The point is that even transactions without confirmations can be made safe enough, so that ordinary merchants or users can send transactions and not have to worry about long waiting times.
These "technically illiterate idiots" as you call them, such as Peter Rizun, Andrew Stone and Gavin Andresen, understand the difference. There are also suggestions to improve on 0-conf transactions further, making them both safer and also simplifying risk assessment by adding "mini" blocks for quicker high probability confirmations.
Bidding war aren't done to double spend others transactions but to prioritize one's transaction block inclusion.
You said "improve zero conf further" my claim is that RBF does not decrease btc zero conf security but indirectly increases it and that bigger block increase zero conf security to the same extent that a transaction with above average fee on btc is more secure than a lower fee one.
You realize that similar bidding war should occur on BCH with barely more transactions (10x)?
Quicker mini block? Like reducing block time?
Please. I never ever suggested this. You need to consider what I say a little more carefully. One of the effects would be that the overall double spending risk would increase, just as the risk of highly delayed blocks. Sabotage becomes easier on all fronts and even if no sabotage takes place, the payees and recipients may start to lose trust anyways.
In my opinion RBF is mostly useless, but when it has a use it also makes the situation worse overall, even if you can then personally pay extra and bump yourself up in the line. This can of course theoretically always happen, so RBF on its own is a marginal issue. But if anything it makes the particular problem with spam attacks worse.
Yes, similar. A bare 1000% more. For starters. But it's not like people don't understand that.
No, it would establish a lesser worth "weak" block in-between the blocks. Enabling the merchant and payee to easier and more accurately quantify the risk involved. This would also increase the likelyhood that the transaction did get into the actual block. More about this from Peter Rizun if I remember, but there may be others with similar competing concepts developing for BCH.
Now I wouldn't have minded a long conversation on this if it had started out a bit milder, but for now I will need a break. There is more information available elsewhere if you decide you want it.
To most BCASH supporter Replace-By-Fee is a licence to double-spend in reality it's a way for miners to differentiate between legitimate fee pumping over first seen first valid zero-conf security.
If RBF wasn't allowed miners would have had no way of knowing if a 2nd transaction is a malicious double spend or a fee increase. (repeating the same thing sorry)
How does RBF make spam attack worst? RBF lower the total fee paid by allowing everyone to low-ball while still being able to set higher priority fee afterward.
The only negative thing RBF "does" specifically is add fuel to the fire when the rapidly increasing bids are about to or are already coming in. (If the upper limit for on chain transactions is already close, they are about to if we at all expect there to be an increase in transactions.) Since they're not supposed to (at least as far as for normal transactions) on Bitcoin Cash, it would be bad practice to still encourage it as a standard. Imo RBF qua RBF is given too much focus.
I've already acknowledge the contextually quite positive aspect of RBF, but it is only positive in that particular context.
You talk about.
You know blocks should always be full at some low sat/byte?
I've done 5KB transaction for 1 satoshis, It's an oddity that there isn't demand for filling blocks at such low fees. If not only for randomly mixing your coins.
If we didn't have RBF we'd have to do CPFP which adds two input on top of every transaction you want to increase the fee of.
Ps: I wouldn't be spending this much time explaining bitcoin to you if I didn't already had respect and having worked together in the past.
Maybe we can continue this on steem.chat if you want.
Not sure I quite follow you above actually. Blocks "should" not be full, as per the Bitcoin design itself. If your perspective is that they will likely become full at some point, then I can at least see where you're coming from as it was my own for a short while.
I'll leave you a message. But honestly, the divide is still very big here and there's a lot to imply that we'd be better of taking a longer break. In any case, I prefer open and transparent debate when I do it.
Can't edit the post by now, so I'll just put this here.
When I say that the "only negative thing RBF does" is to add fuel to the fire when bids are coming in, I'm including in that whenever someone wants to double spend that way.
By making RBF standard, it doesn't stand out anymore and you have much higher risk for double spends as compared to when replacing-transactions was a rare occasion. In other words, the first seen rule mentioned in the design paper by default (it can always be changed) no longer applies. The function has been inverted.
Excellent friend you are fantastic greetings