Gold collapsing. Bitcoin UP.

[theZerg]

Its slated for .12.x. inca is writing a BUIP so we can formally chuck it.

 

[Roger_Murdock]

A few of us are trying to sort out a technical point in this convo:

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.

 

[JVWVU]

And Peter Todd falls in line and 100% consensus in Core devs?

 

[Zarathustra]

I am withholding my formal candidacy in the hopes that someone who has more experience with Bitcoin and more importantly is paid full time wants to run. An engineer sponsored by some Bitcoin company (or group of companies) would be a good choice.

Those companies should choose you. I would vote for you.

 

[Peter R]

@Zangelbert Bingledack , @Roger_Murdock

Yes, I think we're learning something new here. This is my take:

 

[Inca]

Its slated for .12.x. inca is writing a BUIP so we can formally chuck it.

I will have something in the next day or so.

 

[Peter R]

@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?

 

[Mengerian]

@Inca, @Peter R How about if BU lets the user decide whether to enable RBF or not?

This would align with the philosophy of empowering the user to choose how the software behaves.

 

[Peter R]

@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...

 

[Zangelbert Bingledack]

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.

 

[cypherdoc]

@cypherdoc

Here is a great analysis by Adriano Celentano about the situation. He totally agrees with you, and not just since yesterday. Listen carefully:

if i only understood Spanish

 

[Zangelbert Bingledack]

@Peter R @Roger_Murdock

Here are my thoughts as of now.

 

[Zangelbert Bingledack]

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

 

[cypherdoc]

here's the 20 yr weekly chart of the VIX volatility index. you decide; is volatility starting to pick up?:

 

[rocks]

in this Joseph Poon post from 2mo ago, you see that all these changes being slipped into the code, like OP_CLTV, nSequence, RBF are all meant to make LN work more smoothly. it appears that those listed are partial fixes rammed in when SW would definitively fix malleability with one fell swoop. but that doesn't stop core devs from inserting them anyways just in case they can't get SW. so how much more complexity creep do these additions create?:

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]

@Inca, @Peter R How about if BU lets the user decide whether to enable RBF or not?

This would align with the philosophy of empowering the user to choose how the software behaves.

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]

And Peter Todd falls in line and 100% consensus in Core devs?

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.

 

[cypherdoc]

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]

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.

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?

 

[Matthew Light]

AFAIK RBF is a behavior of the mempool, and doesn't have anything to do with the blockchain.

 

[Zangelbert Bingledack]

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."

 

[theZerg]

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.

 

[Zangelbert Bingledack]

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.