Gold collapsing. Bitcoin UP.

[Richy_T]

The point is that with TTOR, miners can still enforce chronological order at a later point. At scale you have a timechain as fine as 10min*(1/numOfTransactions).

You're going to explain how you do that because it sounds to me like something that's not possible with TTOR as implemented even if you remove sort-by-fee.
[doublepost=1554213603][/doublepost]

I recognize weak blocks / subchains when I see them.
CC @Peter R

I think weak blocks etc are great. But as soon as they're compulsory and miners reject other blocks, it's arguably not really Bitcoin any more.
[doublepost=1554213803][/doublepost]

honest question, if I may.

Can we agree that the following statements are true?

a- @Richy_T showed that in past blocks the correlation between txns order in a block and time of arrival in a miner memepool is close to 0.
b- There's no timestamp field in the data structure used to store transaction data. (https://en.bitcoin.it/wiki/Transaction)
c- Txn time of arrival could be in conflict with the actual topological ordering (this could happen quite frequently)

edit: correct a typo in Richy_T's nickname

I'd also add that time of arrival is *purely* anecdotal. If it was recorded, any miner could invent any value it wanted and no other miner would have grounds to question its validity. Hence Bitcoin's design.
[doublepost=1554214342,1554213498][/doublepost]And I mean not just the lack of transaction timestamps but the whole "let's solve it as a block" thing.

 

[79b79aa8]

> I'd also add that time of arrival is *purely* anecdotal. If it was recorded, any miner could invent any value it wanted and no other miner would have grounds to question its validity. Hence Bitcoin's design.

but there is no incentive for miners to do that, and it incurs a cost. whereas in the original scheme the miner preserves the natural tx reception order, only adjusted for orphan txs in order to preserve block validity. granted, had a different miner mined the block, txs would appear in a different order, but propagation times are small and the history would not be completely different. with CTOR this information is just lost. such coarse granularity increases pressure for that other bugbear, more frequent blocks.

 

[sickpig]

but there is no incentive for miners to do that, and it incurs a cost. whereas in the original scheme the miner preserves the natural tx reception order, only adjusted for orphan txs in order to preserve block validity

Thing is that even if they wanted to change it, they can't, at least not directly.

As @Richy_T there's no such a thing as time of arrival in the sense that this timestamp for each txn is not recorded anywhere in the chain, nor in the block headers nor in the tx data structure.

The only thing you could speculate upon is *if* miners works in append only mode (modulo dependents txns) to build blocks, but you have no way to be sure they are actually doing it.

Miners do process txns in append mode but at the mempool level they can't to do otherwise, but this is not enough to guarantee you they will do the same at the block level.

What if a particular sort criteria will cost X but will let you decrease your validation time by 100X? Would you as a miner push for this kind of criteria to be included in the set of the consensus rules?

 

[cypherdoc]

>What if a particular sort criteria will cost X but will let you decrease your validation time by 100X? Would you as a miner push for this kind of criteria to be included in the set of the consensus rules?

what's been made clear to miners is that changing concensus rules, even if it means potentially decreasing miner's validation time by 100x, has severe consequences.

 

[sickpig]

@cypherdoc mine was just an example and I could have phrased differently.

either way there's even no need to change the consensus rules. a BTC/BSV miner could do it on a voluntary base. A part from the dependents txns they could currently order the rest of the bunch in whatever order they want.

 

[cypherdoc]

@sickpig i think given what is happening with the heretofore successful production, propagation, and validation of 128MB blocks in BSV w/o delays, you'd have to explain why miners would freely change away from append only chronological ordering of their blocks when it involves a cost to do so (@Richy_T should run his analyses on recent BSV big blocks to verify this). and if they don't, and i don't expect they will if BSV continues to increase the limit or remove it all together, accountants, financial institutions, and lawyers will find that analyzing a blocks tx's will be much easier although admittedly not perfect.
[doublepost=1554221203][/doublepost]this is what i like about the BSV model; it's undergoing live testing on mainnet everyday with huge blocks that were deemed impossible to reliably process by many here in this thread. whereas the benefits of CTOR exist purely as an untested hypothetical.

 

[freetrader]

I think weak blocks etc are great. But as soon as they're compulsory and miners reject other blocks, it's arguably not really Bitcoin any more.

I think weak blocks are good too, and I'd like to see them implemented in a way that does not force consensus on others.

About the "not really Bitcoin any more" point:

I agree it would be a significant departure from Bitcoin's original design. Adding Avalanche with consensus requirements would be the same departure to me.

But IIRC recall correctly, @Peter R 's paper introduced subchains without a requirement to orphan any weak or strong blocks, but with the option to consider such for a possible additional improvement.

Finally, Bitcoin can evolve in the form of Bitcoin Cash.

I'm happy to let the nChainers and BSV fans carry on the experiment of completely freezing the original design (though I don't believe their Chief Scientist on that intention even if he states it).

 

[attila]

Miners intentionally "fix history" to guarantee a topologically valid order.

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

A node may receive dependent transactions in _inverted_ (yes, invalid!) order. So chronologically ordered blocks might not even make sense.

That's besides the point. We know for fact that the dependent transactions were signed by the parties in chronological order.

But, as a matter of fact, Bitcoin0.1 and also bitcoin-sv right now don't store history any better than BCH.

No. As a matter of fact, BCH is the only one that explicitly cannot support chronological ordering because the causal ordering is not respected. Causal ordering is a necessary condition to meet the definition "chronological".

 

[cypherdoc]

>That's besides the point. We know for fact that the dependent transactions were signed by the parties in chronological order.

we're really discussing independent tx's which comprise the majority of a block's tx's.

i was trying to think of an example of where chrono ordering would be of importance at the intrablock level. one might be exchange wash trading occurring from independent addresses that someone might be trying to hide from the accountants.

 

[lunar]

@cypherdoc

 

[sickpig]

@sickpig i think given what is happening with the heretofore successful production, propagation, and validation of 128MB blocks in BSV w/o delays

Unfortunately I have no data to back up this your statement because I don't currently have any node on BSV chain currently. The only thing I recall is that lately a bunch of big blocks (> 100MB) lead to an explore or 2 to crash.

having said that I will soon give it a try so at least I could witness first hand how propagation of those big blocks is actually working for me.

@sickpig
you'd have to explain why miners would freely change away from append only chronological ordering of their blocks when it involves a cost to do so

I guess miners will start changing (if ever) the way they pick the txns to put in a block as soon they'll find profitable to do so.

 

[attila]

Also, note that BCH clients do have a CTOR->TTOR algorithm, which is used when a block is disconnected (eg a reorg). Once-confirmed transactions that are not part of the longest chain need to go back into the mempool and ATMP requires them to be in topological order.

In other words, the old code sorted chronologically.

When there are no causally related transactions, then the other transactions can be sorted in any order and still be considered chronological.

How is this possible? The system 'Bitcoin' is creating a timestamp server from first principles (ie: you cannot refer to outside clocks). Therefore, from the frames of references from the outside observers looking at the miner/mined blocks...it makes no difference as long as causality is preserved.

Time has no meaning outside the relationships to other events.

If you don't want to follow this line of reasoning (you would be wrong not to, but that's alright), then I can go with the statement that the old code still sorted in partial chronological order. Which, for all use-cases, is just as good as full chronological. That's actually is the best that can be in this universe.

The problem is when the blocks are not even sorted in partial chronological order you lose the ability to create and verify the timeline of events in O(n) time.

 

[bsdtar]

> When there are no causally related transactions, then the other transactions can be sorted in any order and still be considered chronological.

Good. Thus a BCH block after a CTOR->TTOR algorithm can "still be considered chronological".

> The problem is when the blocks are not even sorted in partial chronological order you lose the ability to create and verify the timeline of events in O(n) time.

Oh, so now the problem is not that your accountant can't recover history, but that it takes a little longer to do so?
[doublepost=1554224862,1554224051][/doublepost]

@sickpig, you'd have to explain why miners would freely change away from append only chronological ordering of their blocks when it involves a cost to do so (@Richy_T should run his analyses on recent BSV big blocks to verify this).

Currently it's not append only. Bitcoin-sv is sorting transactions by priority and then by package fee rate. Also, since you mentioned cost, you do realize that sorting is one of the most inexpensive parts of generating a block template, right? If we had a continuous block template production, inserting/appending one new transaction is incredibly cheap, recalculating the merkle root is expensive.

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.

 

[cypherdoc]

@bsdtar

>Bitcoin-sv is sorting transactions by priority and then by package fee rate.

that's interesting. can someone confirm this? the question then becomes, why would they be needing to do that when miners can inexpensively gobble up their entire mempools with all their tx's w/o fee sorting?

 

[lorenweidenbach]

With all the fluctuations that have happened in the market i am wondering if anyone here are active traders that try to buy low and sell high similar to stocks. I am aware that there are funds and such that have showed up on the stock market but i am talking of direct coin trading.

Anyhow the reason for the inquiry is because i see many opportunities for such to be done and i am really interested if anyone has had any luck at predicting the fluctuations. It looks as though we now have a base price of around 3500. Other than whales selling off it and big moves inside the market it is now steady so even let's say a 500 rise could gain much funds if done correctly.

We might as well take advantage of the new found ranking or federal definition of btc now considered to be a security and bound by the rules of the SEC. For any who were not paying attention this happened when Floyyd Maywheather Jr. and DJ Khaled were charged for securities fraud for not registering for being spokesman for btc after receiving coins for promoted coins.

I will get the fun started with a prediction here for any to take advantage of. I see a temporary rise for the next couple days that will go to around 4000 then quickly drop right back to base. Lets see what happens.

 

[79b79aa8]

@Zangelbert Bingledack your very interesting examples assume that the purported improvements are introduced in good faith. the situation is obviously worse if foul play is involved. small blockism is so outlandish that one has to wonder.

 

[freetrader]

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.

Hey @bsdtar, I'd be interested in a list of your strongest contra-CTOR arguments, sorted according to strength

 

[79b79aa8]

that's the wrong way around. in order to change in the consensus rules, stupendous arguments in favor of CTOR needed to have been advanced first. they were not. we had an assertion of power instead.

 

[Peter R]

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.

 

[shilch]

You're going to explain how you do that because it sounds to me like something that's not possible with TTOR as implemented even if you remove sort-by-fee.

Why should this not be possible?

I'd also add that time of arrival is *purely* anecdotal. If it was recorded, any miner could invent any value it wanted and no other miner would have grounds to question its validity. Hence Bitcoin's design.

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.
[doublepost=1554233350][/doublepost]

recalculating the merkle root is expensive.

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.