Its slated for .12.x. inca is writing a BUIP so we can formally chuck it.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Roger_Murdock
Active Member
- Dec 17, 2015
- 223
- 1,453
Here is my thought process. All fees incentivize hashing. And all hashing contributes to security. Because the level of security is really just the cost of a 51% attack, no? Now you might think, well, to the extent that hashing power spent producing orphaned blocks "could have" been spent creating un-orphaned blocks, orphaning is associated with a reduction in difficulty. And lower difficulty means that it would be less expensive to acquire the necessary hardware for a 51% attack, no? (The attacker can make his attack blocks lean and mean so that they're not subject to the same orphan risk as honest miners. Or to think about it another way, when a good chunk of the network's hashing power is "diverted" to orphaned blocks, an attacker would seem to need less than 51% of the network's total hashing power for an attack.) But making small blocks when there are lots of fee-paying transactions to be had (the whole reason that other miners are bearing the risk of orphaning and making larger blocks) is itself a kind of cost. Furthermore, honest miners would have an easier time responding to a lean-block 51% attack by themselves making smaller blocks to counter it. (They essentially have extra hash power in reserve that they could draw on.) So no, I don't see how orphaning risk reduces PoW security in any real meaningful way.
Zarathustra
Well-Known Member
- Aug 28, 2015
- 1,439
- 3,797
@Zangelbert Bingledack , @Roger_Murdock
Yes, I think we're learning something new here. This is my take:
Yes, I think we're learning something new here. This is my take:
- Aug 28, 2015
- 517
- 1,679
@Inca
I agree that BU should NOT support producing RBF transactions. But a BU node may still receive RBF-enabled transactions from other clients. Do you think we should treat them as non-standard and not forward them too?
I agree that BU should NOT support producing RBF transactions. But a BU node may still receive RBF-enabled transactions from other clients. Do you think we should treat them as non-standard and not forward them too?
- Aug 29, 2015
- 536
- 2,597
@Mengerian
I would be fine with that if someone wants to code it up. In that case, I think the default setting should be RBF=OFF because BU's Vision Statement supports zero-confirmation transactions.
That being said, if no one would turn it on, then why bother doing the work to add the option. We'd need to poll our users...
I would be fine with that if someone wants to code it up. In that case, I think the default setting should be RBF=OFF because BU's Vision Statement supports zero-confirmation transactions.
That being said, if no one would turn it on, then why bother doing the work to add the option. We'd need to poll our users...
Last edited:
Another option is to force the user to pick ON or OFF at startup. Best of both worlds. Recommend OFF, but make it clear that Core setting is ON.
Actually, I guess with @solex's BUIP, "Core settings" could be just another dropdown menu setting. Then the user wouldn't be exposed to it at all unless they wanted Core mimicry specifically.
Actually, I guess with @solex's BUIP, "Core settings" could be just another dropdown menu setting. Then the user wouldn't be exposed to it at all unless they wanted Core mimicry specifically.
Last edited:
Someone's working on making the forking process less fragile. I think I predicted this would happen a year ago.
https://github.com/tomasvdw/bips/blob/master/decentralized-improvement-proposals.mediawiki
https://github.com/tomasvdw/bips/blob/master/decentralized-improvement-proposals.mediawiki
here's the 20 yr weekly chart of the VIX volatility index. you decide; is volatility starting to pick up?:
And all those changes are essentially the only work they have done on bitcoin over the past year or so. There has been not only zero work done on real scaling solutions, but active rejection of others' proposals to start work on scaling solutions.
There simply needs to be a new group of developers working on the interests of users. Hopefully coinbase, bitpay, bitstamp and others see that now.
[doublepost=1451507068][/doublepost]
The correct behavior according to satoshi's design is for all nodes to reject double spend transactions and refuse to relay them or mine on them. This is the only way to protect the "instant payment" part of the design. RBF is an attack on that design.
It feels to me that enabling RBF in any form is incorrect and that it should not even be an option.
My vote (if there is one) would be to launch BU as not accepting RBF and continue to reject double spends to protect the network, which is the current behavior of ALL clients today btw.
Then after BU gets established we can let BU's voting mechanisms on which features to add work for this. If the voting mechanisms vote for adding a change that let users turn on RBF, fine. But I'd say let it go through that process than to start off with RBF today, which again isn't even in core today.
[doublepost=1451507322][/doublepost]
Too bad there is large consensus among users and companies against that "scaling" plan. And that was with thermos' help.
There arrogance here is astounding, it feels that we are dealing with children.
Last edited:
sometimes junk really is junk:
[doublepost=1451507680][/doublepost]hey, did somebody just ring the bell?:
[doublepost=1451507755][/doublepost]Big dump...
[doublepost=1451508376,1451507520][/doublepost]that is just awful. 2 of the world biggest mines. 10 yr weekly:
[doublepost=1451509200][/doublepost]
if core inserts this and BU doesn't, won't BU then never be able to follow the 1MB core chain even if it is the longest?
[doublepost=1451507680][/doublepost]hey, did somebody just ring the bell?:
[doublepost=1451507755][/doublepost]Big dump...
[doublepost=1451508376,1451507520][/doublepost]that is just awful. 2 of the world biggest mines. 10 yr weekly:
[doublepost=1451509200][/doublepost]
i totally agree with this sentiment but that brings up a technical question for @theZerg .
if core inserts this and BU doesn't, won't BU then never be able to follow the 1MB core chain even if it is the longest?
At some point the project has to decide finally whether it wants to be able to be "unlimited" in the sense of being able to track all the major option sets out there (which would obviously include everything in Core, at least as a goal), or whether it wants to actually promote or discourage something so much as to not even have it as an option to turn it on or off.
To me, it seems self-defeating to leave out the option to enable RBF if Core includes it, because the whole idea of BU seems to be that it is pointless to try to create a wall of inconvenience for the user in an attempt to set policy. That inevitably means making it easy for the user to include changes we would all disagree with. If not, it becomes more like XT: a Bitcoin proposal rather than a platform that lets the user choose at their own risk.
From all three angles of practicality, philosophy, and PR, deliberately choosing not to include the full set of Core features as options seems to me a mistake. Practicality because it's merely a wall of inconvenience; people can mod BU to add it in if they really wanted to. Philosophy because it blurs the "unlimited" message, which I think is a message of neutrality that could otherwise contribute greatly to a resolution of the debate and removal of paternalistic control over consensus parameters by Core (how can BU claim that if it also has paternalistic "we're deliberately not gonna let you do this" aspects to it?). PR because we can no longer tell people, "It's exactly like Core unless you change the settings."
On the options menu, it can always have a big warning that RBF sucks donkey balls
I had idea that Bitcoin Unlimited said something like, "I disapprove of your settings, but I will defend to the death your right to set them."
To me, it seems self-defeating to leave out the option to enable RBF if Core includes it, because the whole idea of BU seems to be that it is pointless to try to create a wall of inconvenience for the user in an attempt to set policy. That inevitably means making it easy for the user to include changes we would all disagree with. If not, it becomes more like XT: a Bitcoin proposal rather than a platform that lets the user choose at their own risk.
From all three angles of practicality, philosophy, and PR, deliberately choosing not to include the full set of Core features as options seems to me a mistake. Practicality because it's merely a wall of inconvenience; people can mod BU to add it in if they really wanted to. Philosophy because it blurs the "unlimited" message, which I think is a message of neutrality that could otherwise contribute greatly to a resolution of the debate and removal of paternalistic control over consensus parameters by Core (how can BU claim that if it also has paternalistic "we're deliberately not gonna let you do this" aspects to it?). PR because we can no longer tell people, "It's exactly like Core unless you change the settings."
On the options menu, it can always have a big warning that RBF sucks donkey balls
I had idea that Bitcoin Unlimited said something like, "I disapprove of your settings, but I will defend to the death your right to set them."
Last edited:
just like "excessive" blocks, we are must accept the transaction that gets put in a block. After all, we can't prove that txn A happened before txn B.
So we are left just not relaying RBF (and not mining the higher fee txn ofc). The problem with that is that nodes then don't see that there is a double spend attempt. I wonder if we could sabotage the 2nd txn before passing it along...
EDIT: ZB I think that you are right in general. This is a bit of a special case because the importance of 0-conf transactions is explicitly stated in our Articles. So on that basis we could have an exception to our usual behavior of configurability. But I'll go with whatever the community decides here -- its just as easy to add a configurable as it is to comment out the code.
So we are left just not relaying RBF (and not mining the higher fee txn ofc). The problem with that is that nodes then don't see that there is a double spend attempt. I wonder if we could sabotage the 2nd txn before passing it along...
EDIT: ZB I think that you are right in general. This is a bit of a special case because the importance of 0-conf transactions is explicitly stated in our Articles. So on that basis we could have an exception to our usual behavior of configurability. But I'll go with whatever the community decides here -- its just as easy to add a configurable as it is to comment out the code.
Since in the Articles there is also strong support expressed for letting the user decide, it seems to me a harsh warning not to enable RBF would be sufficient. Otherwise I don't see how we can keep to both principles at the same time.
Meanwhile we could add in some other options that would try to counteract it. That seems to live up to both ideals.
Meanwhile we could add in some other options that would try to counteract it. That seems to live up to both ideals.
