Gold collapsing. Bitcoin UP.

[Richy_T]

Part of the point is that you can't really. That's why Bitcoin is designed to confirm things in blocks. I mean you can, sort of but then you're not really using the benefits of Bitcoin. Which is why LN is ultimately doomed.

 

[Norway]

Sorry, @Richy_T . Good luck with your 10 minute timestamps and a 32 MB limit administrated by a handful of central developers on BCH. I'm heading for a better future without limits where the protocol is set in stone.

 

[Richy_T]

Those 10 minute timestamps aren't going to magically disappear. Good luck hanging with Craig and remember to count your fillings.

 

[Norway]

No, the loop is not complete now, merely a short-circuit has taken place in your brain, resulting in faulty logic on your part and calling me a liar.

I won't call you a liar, because I think it's unwarranted since you clearly simply don't understand the point.
No, what's happening here is some kind of physiological or psychological process gone awry.

Hey moderator @freetrader. Why don't you start a new thread on this topic where you try to disprove that you're a liar? Let's go outside, I'm getting embarrassed keeping this topic alive in this thread.

Let's go to another thread.
[doublepost=1554149130,1554148158][/doublepost]

Those 10 minute timestamps aren't going to magically disappear.

What? I don't think 10 minutes timestamps are anything to brag about if you envision a cool sci-fi future.

Good luck hanging with Craig and remember to count your fillings.

That's a good insult! You should give @freetrader a lesson. He sucks at it.

 

[freetrader]

A Roadmap for Eliminating Patents in Open Source
[doublepost=1554150058][/doublepost]

I'm getting embarrassed [...]

Maybe there is hope after all

 

[Peter R]

Those 10 minute timestamps aren't going to magically disappear.

But with the original ordering rules, a future with much finer time-stamping was possible; with CTOR, the "10-min block structure" becomes a lot more visible.

 

[cypherdoc]

I ran through the transactions in the block, in order and requested the fee in sat/B and the received time from blockchain.info (it should be noted that this last information is not in any way recorded in the blockchain).

how did blockchain.info assign a tx received time then? when it hit their mempool? this is probably why I thought somehow a received time was embedded in the raw tx data.
[doublepost=1554151423][/doublepost]

If anyone thinks this block is not representative, I'm happy to run the same deal on any other block. Though some of the early ones are not suitable for various reasons.

you should probably run this on at least 100 blocks scattered across a wide time frame with enough tx's for a representative sampling. I know, easy for me to say.

 

[Norway]

But with the original ordering rules, a future with much finer time-stamping was possible; with CTOR, the "10-min block structure" becomes a lot more visible.

100%
[doublepost=1554151714][/doublepost]I think there is hope to drive the "Aussie Man Bad" virus out of @Peter R's very healthy brain.

 

[freetrader]

But with the original ordering rules, a future with much finer time-stamping was possible; with CTOR, the "10-min block structure" becomes a lot more visible.

I'd like to better understand the reasoning behind this comparative statement. My thinking is that timestamping being only as good as the engineering of the protocol allows for, I don't see the first part being true. If there is any money to be made out of denying finer timestamping, then it costs adversarially minded miners almost nothing to disrupt the "fine-grained timestamping" [1] to a degree proportional to their hashpower.

[1] a misnomer IMO because transactions don't themselves contain timestamps

 

[cypherdoc]

My bet is the prioritization code is still there. but I haven't been following what they've been up to too closely.

I assume you mean fee prioritization. how does this data square with definitive claims by @awemany and zander (guys that presumably work with this all the time) that blocks have tx's that have historically been ordered by TTOR?
[doublepost=1554153065,1554152297][/doublepost]

If there is any money to be made out of denying finer timestamping, then it costs adversarially minded miners almost nothing to disrupt the "fine-grained timestamping" to a degree proportional to their hashpower.

I doubt there would be. Miners try to allow the protocol to achieve as much truth as possible imo. it's best for their investment. yes, that's the optimists view. unfortunately, if this multi chain confusion continues for much longer, thar may no longer hold true.

 

[shadders]

So, TTOR...

I decided to take a look at a fairly arbitrarily chosen block 300,000 (I wanted to go with block 115,000 for obvious reasons but turns out it was uninteresting). This is in a nice range where fees have started to apply but blocks are still far from full and also, blockchain.info have data for received time on transactions (though it should be noted that this will not necessarily agree with the times miners saw them, it should be representative). It is also before the fork.

I ran through the transactions in the block, in order and requested the fee in sat/B and the received time from blockchain.info (it should be noted that this last information is not in any way recorded in the blockchain). I then output the txid, the fee info and the date&time in processed order. The TXID was shortened for readability but is still verifiable from the block itself.

https://pastebin.com/6r8nv4cc

What can be seen is that the order in the block, while not a totally monotonic for either fees or received time, does bear a strong correlation with decreasing fees wheras the received times are all over the place, apparently having no, or very little correlation to block position at all*.

So, the conclusion, as it appears to me, is that TTOR provides no useful or usable information in the general case at all and has benefits for implementation specific optimizations only.

*This is clear to me but if anyone would like this shown as a graph, I would be happy to supply.

If anyone thinks this block is not representative, I'm happy to run the same deal on any other block. Though some of the early ones are not suitable for various reasons.
[doublepost=1554139645][/doublepost]Note there may be some age priority stuff going on there. This block is from before that stuff was removed.

What you're seeing the result of core's 1mb limit fuckery. When you assume block sizes are constrained you gain a requirement to pick the highest fee transactions first to ensure you're building the most profitable block when the mempool is larger than block size. We've spent a lot of time working out this mess lately, so much code spaghetti (and quadratic computation cost) is dedicated to solving this non-problem. It's further complicated by ancestor calculations so transactions are not added one by one, they are added in packages of descendants (hence why the fee's aren't perfectly in order). Then end result is that transactions are NOT ordered naturally as they were in 0.1.0.

If you assume unbounded blocks this all goes away. There's no need for any fee sorting. The assumption is that ALL eligible txs will fit in the block.

The process is simple: receive tx. Is valid? Is fee above minimum? Yes? Ok append it to the block template.

The only exceptions are low fee CPFP parents that won't go in until a child meets their fee. Until block limits are removed completely there *might* be the occasional block produced that is not quite fee-optimal but given the vast capacity improvements a simplified block building algorithm enables the loss will likely be more than offset.

In anticipation of your question, yes we will be changing this back to the way it was. Work is already in progress.

 

[Norway]

EDIT: Continuing from post above...

In fact, I know @Peter R see the value of a stable protocol. He states that protocol changes should be "slow". But how slow is slow?

@Peter R. We are making a global contactless payment protocol right now. And we make the hardware/software combo that works with it. I have said it before, and I'm proud to say it again:
I was very inspired by your SigSafe project to start this adventure.

Underway, we discovered that the payment protocol itself was even more important than just "programming" both devices and make a tx happen.

We also see tokens as a huge opportunity where bitcoin (BSV) can compete with established token systems.

So how slow is slow?
Our first hardware will be JavaCards. Schnorr signatures would be most likely impossible (not supported directly by hardware, and process time is very important. Nobody wants to use a minute to pay for goods over a counter.)

We want our first cards to last for many years for the consumer. As a hardware wallet, as at token tool and as a BSV payment device.

Many years!

Scaling bitcoin to the world is possible without changing the protocol itself.

I feel like I was fed a lie by @theZerg when he proposed his OP_CODE to make it possible to "bump" phones and make bets based on an oracle not knowing we were betting.

When I poked my nose into this, I discovered it could be done with the current script language.

Bitcoin, in it's original form, is awesome. The problem is when people try to fix it.

Gavin raised the issue of governance as a problem.

Craig Wright, the inventor of bitcoin, have the solution: Don't screw with the protocol!
If nobody screws with the protocol, there are no problems. Just trivial engenieering.

 

[cypherdoc]

his analyzed block though was from 2014 when there wasn't any significant congestion. @shadders

 

[Norway]

@cypherdoc

his analyzed block though was from 2014 when there wasn't any significant congestion. @shadders

True. But it doesn't mean miners knew how to make bitcoin valuable. They are all over the place today.

 

[shadders]

his analyzed block though was from 2014 when there wasn't any significant congestion. @shadders

I'm going to guess the 'select highest fee txs for block first' was there before congestion kicked in... The assumption at the time may not have been permanent 1mb block but it certainly assumed there'd be a block limit for a very long time.

Maybe I should double check but I'm 99% certain the original code didn't do any sorting.

 

[Norway]

The sorting is not a consensus rule. Because it's relative to the miner.

Miners have an incentive to keep the books in order. Not sure if all sha256 miners know this. But they can be punished to understand by the rest of the miners.

 

[Richy_T]

What? I don't think 10 minutes timestamps are anything to brag about if you envision a cool sci-fi future.

*shrug*. It's the way Bitcoin works. Especially if you're going to set the protocol in stone. Of course, luminaries such as Charlie Lee have taken bold steps to address these shortcomings in the past.

 

[shadders]

That's exactly why I believe it's not a consensus rule. Bitcoin solved the problem of granular timestamping by consensus but in a latency filled system could never solve it by hard consensus at millisecond granularity. But in time if the value of more granular ordering is recognized by miners I would expected a softer 'semi-consensus' to emerge where if this ordering is respected other miners will respond with behaviour that favours those that accept the consensus.


Its kind of the opposite of the tragedy of the commons.

 

[Richy_T]

Incidently, I didn't mention it but another reason I didn't use an older block in my analysis is because for many older blocks, blockchain.info didn't have the historical data for when those transactions were received. They still had the "Received" field for those transactions though. The information in that field? The timestamp for the block they were confirmed in.

 

[Norway]

@Richy_T
Your altcoin will never reach a settlement granularity less than 10 minutes.
[doublepost=1554158169][/doublepost]Do you think Avalanche is a good thing? It's coming to BCH. And it will orphan a non-avalanche node with proof of work if this node disagrees with the Avalanche cloud.
[doublepost=1554158321][/doublepost]Any hints on when bip270 draft is ready @shadders? This is what my company really cares about today ...