Gold collapsing. Bitcoin UP.

[Richy_T]

but there is no incentive for miners to do that

Ah, but if that were the scenario, incentives would arise. If there's a reason for storing timestamps with the transactions, there's a reason why 8:31:59 is better than 8:32:02 and if there's a reason it's better, then that reason is probably money and suddenly there's the incentive to pay a miner to lie.
[doublepost=1554233967][/doublepost]

(@Richy_T should run his analyses on recent BSV big blocks to verify this)

I'll see if I can get around to this. It will involve some run-up effort as I don't run a BSV server. The only reason I even run a BTC server these days is cause I just can't quite give up on Chartbuddy yet.

Though actually, I could run it directly from the explorer. I just like to get my data first-hand if I can.
[doublepost=1554234155][/doublepost]

It is a necessary condition that dependent events happened in the past.

But that's all you need to say about that. Putting them in order in the block doesn't make it any more or less the case.
[doublepost=1554234254][/doublepost]Let's not forget that anyone who runs a node (or compatible software) can themselves record when transactions were first seen (from their point of view).
[doublepost=1554234600,1554233734][/doublepost]

Just to be clear again, I don't support CTOR. There are strong arguments against it, but 'history is lost' or 'cost' aren't really strong ones.

Good point. I think the main thing I and probably you and others would prefer is to get past this point and move on to discussing points that actually have merit. Though it's not really an issue I care too much about. I do think CTOR was premature and thus completely unnecessarily helped with the split (though I'm not sure how much BSV thought leaders were just looking for an excuse. BCH certainly gave them one).
[doublepost=1554234797][/doublepost]

Why should this not be possible?

Because there's no mechanism to do what you intend in the data structure. You're going to have to show how you intend to do it if you're claiming that it can be. What I see is:

1) TTOR
2) ???...
3) Profit Timestamped transaction accounting system.

And part of the reason you're going to have to show how you intend to do it is because however it works for TTOR, I'll bet it can be used with CTOR too.

[doublepost=1554234941][/doublepost]

Well, if you include a transaction that no other miner saw, they will probably ignore that. But if like 20% of the transactions in your block haven't been observed by any other miner, you'll likely get orphaned.

Really? How so? Heck, we were having trouble at one point having miners actually validate blocks at all. As it is, the miners simply validate any foreign block, including validating all the transactions in the block and if it checks out, move on to the next block. Miners only care about incoming transactions in as much as it allows them to build the next block

 

[bsdtar]

@freetrader:

1) It wasn't worth a split. Core always knew this...
2) A next step in the scaling plan is to use a merklix tree, which doesn't care about ordering. All those "CTOR-exclusive" propagation benefits would still be possible with TTOR. So, why bother then?
[doublepost=1554238141][/doublepost]

It's not. I wrote an article about that a while ago: https://www.yours.org/content/scaling-bitcoin-s-merkle-tree-936c950c63d6
You can calculate a merkle tree root for a block containing 70 million transactions (27GB block) with fairly new hardware in about 400ms.

When I said expensive, I was comparing to sorting. Anyhow, nice post, I enjoyed reading it. Yeah, so merklix seems unjustified =) Btw, what you described in that section titled 'Updating extraNonce in coinbase' is exactly what mining hardware and poolservers do.

 

[attila]

Though it's not really an issue I care too much about. I do think CTOR was premature and thus completely unnecessarily helped with the split (though I'm not sure how much BSV thought leaders were just looking for an excuse. BCH certainly gave them one).

There is no split.

Bitcoin was created
BTC forked away from Bitcoin protocol
BCH forked away from Bitcoin protocol
Bitcoin protocol continues and is operational still...

It's neither here nor there what "thought leaders" thought about things. BCH is not Bitcoin as clearly defined in the white-paper. If someone forks off TCP, then they are not using TCP anymore. What other people think about TCP does not change the reality anymore than if someone started calling a "cat" a "dog".

 

[Richy_T]

Whatever. Point stands.

 

[freetrader]

@bsdtar thanks for those points.

1. I guess so, but I don't buy CTOR as the sole reason for the split, but rather a pretext

2. This is a much more interesting angle. I wonder if @deadalnix or anyone else from ABC would care to comment.

I don't see though how you arrive at "All those "CTOR-exclusive" propagation benefits would still be possible with TTOR."

The prime motivation for CTOR seems to be to exclude ordering information from being necessary on the network. Hence its use in Graphene now. Those present benefits would be reduced by TTOR-only.

The point of how this would all be impacted by a move to Merklix tree block structure needs to be addressed.

 

[cypherdoc]

congrats to all those who had the patience to hodl the onchain scaling protocols.

 

[RollieMe]

I've done accounting for small businesses and large corporations and I'm not sure I understand the benefits of ordering for accounting. Banking, sure, but not accounting. Accounting reports are prepared periodically (annually, monthly, more regularly if you are big enough) and they are always prepared at a point in time. It's irrelevant to the results if say if all of the debits in that period were recorded first and then the credits. All that matters is the balance at the close of that period.

 

[attila]

@RollieMe

Did you record transactions in your ledger in chronological order or another order?

 

[bsdtar]

@freetrader
> I don't see though how you arrive at "All those "CTOR-exclusive" propagation benefits would still be possible with TTOR.

If/once we move to a merklix tree, the block header will commit to a set of transactions instead of a list. Ordering information won't be necessary anyway, so nodes can serialize the full block in any order they like. This includes TTOR and we'd still keep all the propagation benefits that CTOR gives us (yeah like graphene).

Yes, it was a pretext. There were a bunch of senseless arguments like wormhole, DSV as a subsidy, DSV and patents, CTOR helps sharding, difficult changes first, etc ... But I can't shake this feeling it was only a powerplay resulting from huge miscommunication. Somehow CTOR and other features couldn't be delayed and yet we have no significant upgrade for the next HF?

 

[RollieMe]

@RollieMe

Did you record transactions in your ledger in chronological order, or did you hash the receipts and store them lexicographically or in another manner?

They're recorded in the order the bookkeeper becomes aware of them or is told to record them. He might start with journals based on documents reflecting actual transactions, then do journals for rolling provisions he does each month, then well after the period has actually closed he might do journals that the accountant gave him to adjust things. He might record those as happening at the start of the period, or the end of the period but it only usually matters that they are recorded as happening within the period. The order they are recorded doesn't really matter for anything appearing in an account balance that gets rolled up to a profit and loss statement or balance sheet report - only the balances at the close of the period (year, month, week or whatever).

 

[attila]

@RollieMe

I see what you're saying -- correct the accounting reports do not care for the chronological ordering. The book keeping and transactions ledger is chronological, which are in turn used to generate those reports.

 

[cypherdoc]

It's not. I wrote an article about that a while ago: https://www.yours.org/content/scaling-bitcoin-s-merkle-tree-936c950c63d6
You can calculate a merkle tree root for a block containing 70 million transactions (27GB block) with fairly new hardware in about 400ms.

i remember reading your great article and having it go down as another nail against Amaury's merklix proposal. my favorite part:

What can we learn?

These simple tests have shown that merkle trees DO scale. There certainly are some challenges when it comes to scaling bitcoin, but the merkle tree definitely isn't one of them. The so called "vulnerabilities" are well-known and easy to protect against, both implementations of mine I posted here protect against these attacks. I don't think it's worth it to introduce a completely new data structure that hasn't been used in practice for as long as the merkle tree has been - just for a little benefit. If a few developers can successfully change the bitcoin core design because they believe that their protocol design scales better (most of the times without any code to test it), then bitcoin has failed at being stable money that nobody can manipulate. You never know what's the real intention behind certain changes.

 

[cypherdoc]

interesting. CSW is supposed to be deposed Thursday. one shouldn't lie in a depo:

https://www.reddit.com/r/bitcoincashSV/comments/b8rj6f/csw_deposition_will_prove_that_he_is_the_creator/

 

[freetrader]

Judges and jurors can be fooled or bribed, crypto proof can't.

http://hackingdistributed.com/2016/05/02/extraordinary-satoshi-claims/

 

[Zarathustra]

You cannot 'crypto proof' that you are/not Satoshi.

 

[torusJKL]

https://coin.dance/blocks/transactions

TX isn't really a lot higher? Are they tx with large OP_RETURN? OP_RET doesn't take much to process.

What's really important to prove scaling is the average script and CHECKSIG density...

unless your end goal is to have tx with a lot of data. But if so, its not much work for any client to get that.

I think the end goal is to have many different kinds of tx in a block.
The small cash tx, the medium smart contract tx and the large data tx.

 

[theZerg]

Its just important to understand that scaling metrics apply in multiple dimensions and these large blocks mostly show only one of them.

This focuses on the blockchain as data storage and proof of existence at a time.

With a UTXO commitment or cryptographic accumulator, you could see how the full chain history and even utxo set can be not kept on many or even any nodes network-wide. This would make it a lot easier to sync nodes, etc. So these technologies focus on scaling the money function only, and their existence has a practical (but not theoretical) effect on the use of the blockchain as data storage (but not much effect on proof of existence at time because the prover can provide a SPV proof) since it may be harder to find a node with the historical data you need.

 

[79b79aa8]

following up on ZB's post, here is my entirely unsubstantiated speculation on who propitiaded the split: if you have a long-term plan for bitcoin and a couple hundred million dollars to roll it out, and you are firm in your conviction that the original protocol contains all the necessary components to attain domination and changes implemented or proposed are cruft, and you are prepared to spend the next couple of years working on the back end while not worrying about adoption or economic activity, then you are apt to lose patience with having to lobby for the correctives you wish to introduce, and fight against changes proposed by others (whom you see anyway as newcomers or as representing competing interests), with no guarantee of prevailing. all things considered, you will not deem it a loss if there is a network split. so much the better if those others split off on their own accord, which can be encouraged with a little toying around. incidentally, you can continue to apply this tactic as needed to ensure additional strife and time waste on their part.

why then claim there would be no split? facetiously, because you claim (bluff) that you control enough hash to force convergence on your ruleset -- with the available excuse that if phantom hash is brought in, bets are off. or if that was a miscalculation, it doesn't matter, in your assessment you are still better off on your own, free to deploy your strategy unencumbered. at any rate, one who holds this viewpoint estimates that there will be no split in the long run.

disclaimer: this is not an endorsement of anything, just an interpretation of events, which i post because it is different from others i have recently heard voiced.

 

[rocks]

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.

Even if you consider TTOR to be part of Bitcoin's protocol and not just the initial client's implementation, TTOR cannot be used to provide proof of time-stamping as you describe.

Under TTOR you can completely mixup the order of 99.9% of transactions in any given block and have that block still be valid under TTOR consensus rules. TTOR only orders transactions that depend on each other, and the vast majority of transactions do not depend on other transactions in the same block, but on transactions in prior blocks.

The only possible mechanism to achieve finer time-stamp ordering is to do so by extending POW mining to include some form of sub blocks/weak blocks. Doing so provides real world ordering at the granularity of the sub block interval, which could easily be as low as seconds.
[doublepost=1554347242][/doublepost]

CTOR was a bad idea because there was no clear and obvious reason for it. Instead we had handwaving why CTOR was good and handwaving why CTOR was bad. If there is no clear and obvious reason for a change then no change should be made.

As stated before, this is the reason CTOR should not have been done in Nov. The problem is the way it was rolled out, not that it broke Bitcoin's consensus rules (it didn't)

 

[bitsko]

I still think CTOR was rolled out to ensure that investorwin ?