Gold collapsing. Bitcoin UP.

[bitsko]

So with Calvin Ayre saying he doesn't want OP_GROUP yet, it looks to me like we're indeed inching towards a future where the miners decide what will go on.

I would be fine if all of the above proposals become active at 75% miner support for a difficulty period. I trust the incentives to do the right thing

@hodl: As you don't trust signalling: Can you see Calvin Ayre fake-signalling pro OP_GROUP even though he (for now) dislikes it? I really can't.

I suspect the miners want to stay away a bit from being seen as 'responsible for the chain' and the clear signal from a minor now is the exception. But if only the devs propose changes at the 75% level, I think that would make that responsibility a lot more moderated.

I believe you can take Craig Wright's view on things to see what Calvin Ayre will or won't do with his hashrate

 

[awemany]

You assume that you don't have to do that, but you absolutely do. This is exactly why the graphene block is 3 time bigger with ordering, because you ot n*log(n) of info to send through. And then you need to do n*log(n) work to reorder the transactions in the order they where in the block.

That is a fair point, but we don't know yet whether graphene will be the final answer to block propagation. Those of us who want to keep it as it is are simply not certain of the impact of changing this down the road.

For example, I can imagine that you could make graphene transmission deterministic enough that the block order becomes: "As it comes out of graphene, with only those transactions that are interdependent reordered according to this other, XYZ scheme."

Canonical ordering or not, you get to put the transaction in some given order and got to do the work.

But I only need to order those that are interdependent. The others, I can order any way I want. I have requirement for partial ordering now, whereas you intend to make it a full ordering.

Might be worth it, but it is quite a few areas that are impacted by this and this is why I argue to be very cautious. IMO, we should address other issues first and think about this a bit longer.

@bitsko: Maybe. We'll see.

 

[Bagatell]

I believe you can take Craig Wright's view on things to see what Calvin Ayre will or won't do with his hashrate

 

[bitsko]

yeah if anyone wants to bet against me, say $100

my position is we never soft fork in OP_Group.

 

[Richy_T]

For pseudo-chronological ordering, you have to create a pseudo-UTXO set so that you can refer to it as you parse the block for any TXs which have inputs which do not exist in the UTXO set. You have to include even irrelevant transactions in this pseudo TX set since you don't know if they will be relevant or not until you have parsed the last transaction in the block.

For canonical ordering, you can create a lookup table when you receive the block. When a transaction references a TXID which does not exist in the UTXO set, you can check the lookup table and move the relevant transaction ahead of the current one in the validation queue (this may even benefit from parallel validation).

Seems like a wash to me or even tips slightly towards canonical.

Again, disallowing chained unconfirmed transactions simplifies all this even further

 

[AdrianX]

Now ABC opened the door to BU, and you guys come in a shit on the carpet. Let's be very clear here, we as ABC have zero obligation to be cooperative with BU.

@deadalnix BU is not the developers, it's an organization of members we vote on stuff then do it.

Bitcoin Cash is bigger than bitcoin ABC and BU, one would expect we cooperate on enhancing Bitcoin Cash. Honestly, I'm a little disappointed to read this comment.

Non the less I appreciate ABC is governed by a more authoritarian approach Bitcoin Cash benefits from diversity but we owe it to everyone to cooperate.

 

[deadalnix]

But I only need to order those that are interdependent. The others, I can order any way I want. I have requirement for partial ordering now, whereas you intend to make it a full ordering.

Might be worth it, but it is quite a few areas that are impacted by this and this is why I argue to be very cautious. IMO, we should address other issues first and think about this a bit longer.

You get that completely backward. The problem arise when you can order anyway you want, because then you got to transmit that ordering over the wire and then I need to order my stuff to match the ordering you picked.

This is on the table since before graphene was invented. It is not quite a few area that are impacted, pretty much nothing is impacted. It's an enabler.
[doublepost=1519599639][/doublepost]

Bitcoin Cash is bigger than bitcoin ABC and BU, one would expect we cooperate on enhancing Bitcoin Cash. Honestly, I'm a little disappointed to read this comment.

Then imagine how disappointed I am to have to write it. We did everything to foster cooperation and got pretty much exactly zero cooperation + a smear campaign. If you want cooperation, have a good look at what BU's doing right now and act, because at that pace, it'll be full blown civil war before satoshi's vision conference.

 

[AdrianX]

I just argue the way I do because I honestly believe stability and being boring and conservative with [the design of ] money is a virtue.

I couldn't agree more. my interpretation inserted.

 

[Tom Zander]

Bitcoin Cash is bigger than bitcoin ABC and BU

The initial idea was permissionless innovation.

People develop innovations with like-minded people and have the option of emailing to the mailinglist updates to make clear to others what they are working on, to get more eyeballs on it.
Then publish their intention of putting it in the upcoming hard-fork when the deadline date comes.

Permission from other implementations is not needed. People actively making political statements against some ready-coded upgrade which has wide market support is suspect but ultimately irrelevant.

Talk to the miners, talk to the economic majority and definitely ask yourself what the need is for working groups if you end up just being told you are shitting on your "competitor's" carpet.

 

[AdrianX]

Everyone, we're playing a long game, whatever events that have happened over the last week or weeks are insignificant.

I'm not sure what I'm supposed to react too, or what BU could do. That said I am totally looking forward to catching up with everyone in a month time and finding out why this thread has grown 6 pages in a day.

Ther is a need to build stuff and stay relevant, what that is I cant say with any certainty, but one thing I am pretty sure on is it's not building a token network to compete with Ethereum.

As a BU member, there is nothing to react to except some hot heads beating up on stuff.

This feels like dealing with PMS - no offense intended.

 

[AdrianX]

The initial idea was permissionless innovation.

Yes, this is a good point but needs to be put in context. Having predetermined upgrading skedule with Hard Fork potential is not Carte blanche to change things.

Core may have overdone it trying to maintain backward compatibility but permissionless innovation should not depend on a Hard Fork, the types of changes you see in a hard fork should require some vetting.

Permissionless changes don't depend on changing the bitcoin "kernel" which actually needs "permission" ie. miner buy-in and the likes of exchanges and payment service providers.

I like the idea of an upgrade schedule with the potential to hard fork, no should abuse that feature.

 

[awemany]

For pseudo-chronological ordering, you have to create a pseudo-UTXO set so that you can refer to it as you parse the block for any TXs which have inputs which do not exist in the UTXO set. You have to include even irrelevant transactions in this pseudo TX set since you don't know if they will be relevant or not until you have parsed the last transaction in the block.

I don't see how I need to 'keep irrelevant TX' - I just read the blockchain from left to right and update my UTXO set.

Of course I have to order at some point - to ensure that 'CPFP'-like constructions will be properly read.
But that is only when I produce a block.

@AdrianX : Yes that is what I intended to write as well

You get that completely backward. The problem arise when you can order anyway you want, because then you got to transmit that ordering over the wire and then I need to order my stuff to match the ordering you picked.

I don't think I get that backwards, I rather think that maybe I have a different view on the trade-offs. For example, maybe you could go and sync reception order of transactions used in a (weak)block between mempools - the differential entropy might be very low.

Don't get me wrong, I get your points. I simply am not convinced that we have explored every angle sufficiently

 

[Richy_T]

I don't see how I need to 'keep irrelevant TX' - I just read the blockchain from left to right and update my UTXO set.

If you find a transaction which invalidates the block, you have to back all that out. (It is a little simpler than what I stated though).

 

[deadalnix]

I don't think I get that backwards, I rather think that maybe I have a different view on the trade-offs. For example, maybe you could go and sync reception order of transactions used in a (weak)block between mempools - the differential entropy might be very low.

merging two sorted lists is O(n), just like appending n elements to an existing list.

 

[awemany]

If you find a transaction which invalidates the block, you have to back all that out. (It is a little simpler than what I stated though).

Sure, but isn't that just saying that 'validation can fail'? What is special about the order in that regard?

@deadalnix: Yes. But I still have to do the ordering when creating a block and reordering (replacing it with the what-txn-builds-on-what-other-txn, let's call it "txnbuild" partial order) when validating a block.

Whereas currently, I have to only obey the "txnbuild" partial order for those transactions that I want to include in my block and don't have to do any reordering when receiving it. If we would follow @Richy_T's idea of not even allowing interdependent txn in a single block, I wouldn't even have to care about the "txnbuild" partial order other than rejecting that don't fit it, it would simply become part of the txn validity rules. (I don't think that's a good path forward for other reasons, though)

This txnbuild partial order is also highly correlated to reception order of transactions and thus violations are unlikely (though not impossible) when building blocks.

You essentially argue that for network transmission, it makes it easier to sync two sorted sets and that this dwarfs all other concerns. And, yes, again, I can see your point. But also, again, I like to caution here: Are you sure we explored potential paths sufficiently yet?

And the other angle is that for building and validation, you can do with an O(n) instead of an O(n log n) step (modulo details of the current implementations, such as having uint256s in trees instead of hashtables).

 

[jessquit]

The initial idea was permissionless innovation

Well, no. The initial idea was "sound money." In fact it is unclear that Satoshi initially believed that others would be allowed to innovate on the network without his permission. But I digress.

I support permissionless innovation and you are definitely free to innovate by mining a fork that does whatever you want and I'll support that and encourage other devs to support it as well instead of attacking it; just as Core should have supported the big block fork EVEN THOUGH it was in disagreement: because doing so is what's best for all existing holders.

But that doesn't mean that everyone has to agree with your strategies and has to merge your code. Nobody has made anything like a compelling case for how coloring coins makes them work better as "money" because the opposite is true: coloring coins actually makes them NOT "money," so I can't see why I should want that form of currency when instead I could have the simpler form of currency that's focusing on being the best "money."

But you are free to innovate and I will defend your fork from the people that still haven't learned that forking is a perfectly healthy way to grow the pie for everyone.

 

[Richy_T]

Sure, but isn't that just saying that 'validation can fail'? What is special about the order in that regard?

Well, your method is "Add them to the UTXO as you go is a saving" but you can only provisionally add them anyway. Meaning the gain is not as big as all that. Again, I'm not saying one or the other ordering method is better, I'm just saying the argument for "keep them in validation order" is a weak opposition to other orders. I.e. it's fine but if we can get other benefits from a different order, it should definitely be considered.

 

[hodl]

@hodl: As you don't trust signalling: Can you see Calvin Ayre fake-signalling pro OP_GROUP even though he (for now) dislikes it? I really can't.

no, but i certainly can see Wang Chun doing any one of a variety of 180's.

 

[bitsko]

I've been having trouble sleeping soundly lately, been keeping one eye open.

I keep dreaming that @tomz and @Bergmann infiltrate my ranch in the middle of the night and quietly soft fork everything against my will.

 

[adamstgbit]

reading about this TX re-ordering business is pretty cool. all i see is unfounded FUD in opposition. I look forward to a block-chain with optimized ordering!