Gold collapsing. Bitcoin UP.

[Norway]

Welcome @bsdtar!

 

[Richy_T]

@Norway

"But there is no chance in hell I would vote "yes" for your membership unless you are open on your identity."

I was about to say. I was sure I saw your full name on your tweet.

 

[Norway]

Also, note that BCH clients do have a CTOR->TTOR algorithm, which is used when a block is disconnected (eg a reorg).

How do you reconstruct a historic list of events that has been sorted alphabetically?

 

[bsdtar]

It reconstructs one possible topological ordering for a given set of transactions, not necessarily the exact chronological order. You can follow it from here: https://github.com/Bitcoin-ABC/bitcoin-abc/blob/816dbd9150e9ec9a0b45c34af75cf0283e34b973/src/txmempool.h#L899 .

Also, remember that the historic list of events is not the same for every peer in the gossip network. Actually it's not uncommon for children transactions to be received before a parent!! Even the original bitcoin 0.1 had code to deal with orphan transactions.

 

[Richy_T]

After seeing that Gavin Andresen was actually the one to add the first modification of transaction ordering to accommodate Greg Maxwell's "full blocks" designs, surely in an effort at preserving harmony among the committers

I think we have to be wary about looking at things through the lens of 7 years of history. Bear in mind that it had been two years since the Garzik/Satoshi discussion about increasing the block size limit and blocks were still far from full. Though miners were soft-limited to 500k (though were still far from reaching it). Block size wouldn't really re-enter the group consciousness for another year. It's possible Gavin was just looking towards a miner-managed block access effort and not just about hitting the 1MB hard limit at that stage.

It was still a bum steer though.

I did find something else interesting in the commits. I need to work out if it's what I think it is. Interesting if it is.

 

[Norway]

It reconstructs one possible topological ordering for a given set of transactions, not necessarily the exact chronological order.

So it's not a restoration of the timestamps a chronological order represents. It's just a random order where interdependent transactions are given a chronological order. Got it.

History is still lost.

 

[Richy_T]

How do you reconstruct a historic list of events that has been sorted alphabetically?

How do you reconstruct a historic list of events that has been sorted by fee? Further, a list of events you weren't sure of the history of in the first place.

The answer for either is to keep some kind of time stamp as part of the data but to acknowledge that that time stamp is hugely unreliable. At that point, you might give up and throw that time stamp away.

 

[Norway]

It's always cool to see a fresh face here, @bsdtar .

Do you agree that LTOR is degrading history? That BSV have history an accountant can use that BCH doesn't have?

 

[bsdtar]

History, as I said, is not well defined in any way. A node may receive dependent transactions in _inverted_ (yes, invalid!) order. So chronologically ordered blocks might not even make sense. Miners intentionally "fix history" to guarantee a topologically valid order.

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

 

[cypherdoc]

That went over my head.

doesn't the average 1mb block only hold ~2K?

 

[bsdtar]

It's 27kB, not 27K txns =)

 

[Norway]

History, as I said, is not well defined in any way. A node may receive dependent transactions in _inverted_ (yes, invalid!) order. So chronologically ordered blocks might not even make sense. Miners intentionally "fix history" to guarantee a topologically valid order.

Sounds like you're occupied with edge cases. Perfect is the enemy of good.

When Δt -> 0, bitcoin "breaks" from an accountant's perspective. But you really have to do a doublespend attack where you broadcast your first tx at one place, and broadcast the second tx to nodes closer to mining to achieve this.

Keep it real.

 

[Richy_T]

doesn't the average 1mb block only hold ~2K?

Oh, sorry. The number just wasn't in my head so I thought it was some smart comment I'd missed

Yeah, as bsdtar says, it's 27kB.

        " -blockprioritysize=<n> "  + _("Maximum bytes of high-priority/low-fee transactions (default: 27000)\n") +

 

[bsdtar]

Hmm, it's not an edge case, it literally happens ALL the time. I've just restarted my btc node with -debug=mempool: I'm receiving at least 1 txn/s in inverted order (just check the timestamps below).

It doesn't require an "attack". An honest node generating dependent transactions and sending them *in order* will probably result in inverted order in a bunch of other nodes.

But keeping it real: what about my argument that BTC (even 0.1) and BSV don't store history any better? All bitcoins do sort transactions when creating block templates.

2019-04-02T04:04:09Z AcceptToMemoryPool: peer=6: accepted 8ca76b5ccd194a89c585cf123ab62ffde9600030c1db15176fbe383646ec3e04 (poolsz 3488 txn, 18171 kB)
2019-04-02T04:04:09Z  accepted orphan tx fb89b26a60de1d07ef35de2bc9283d09a6c8ca895d55d7a733c5647adb792dfb
2019-04-02T04:04:09Z stored orphan tx 787f9e54a7b1c3b42cf3f35981287ce6e1a4db89a5a8408e145e3adebae8f24a (mapsz 31 outsz 40)
2019-04-02T04:04:09Z stored orphan tx 308c8da967368360d3ea9d5f4dd60120dc8a634cc4f5a4af9480a31af2ef98c0 (mapsz 32 outsz 41)
2019-04-02T04:04:09Z stored orphan tx 1b7eb1d03855defdcc7633a2286c19566c708dde5e7bbac419cd7311d6ed96eb (mapsz 33 outsz 42)
2019-04-02T04:04:09Z stored orphan tx 40a3573ff84b6c555b5042ba2387cdd4949b5d6585e2cb2f4a9f408500ecf717 (mapsz 34 outsz 43)
2019-04-02T04:04:09Z AcceptToMemoryPool: peer=6: accepted 5b2986433b78a28661417705346ba4aca2f1e475cd108de0f8565aa249283055 (poolsz 3490 txn, 18173 kB)
2019-04-02T04:04:09Z  accepted orphan tx 1b7eb1d03855defdcc7633a2286c19566c708dde5e7bbac419cd7311d6ed96eb
2019-04-02T04:04:09Z  accepted orphan tx 787f9e54a7b1c3b42cf3f35981287ce6e1a4db89a5a8408e145e3adebae8f24a
2019-04-02T04:04:09Z  accepted orphan tx adec5aba419f20570d3976864619863e126334418a14ef1fefac3d1194fb1eba

 

[digitsu]

@cypherdoc
Been to so many places, trollboxes, video, articles.... to get as much info as possible before i commit to increase my 25% BSV holding.
It is fair to assume with the avalanche of patent application that he protected BSV of future forks. There is the good and the bad, swim or sink.
I am 100% certain BTC will increase the 21 million cap at some stage (grin is part of this long term plan)
75% convinced BCH will increase also, yet to find a valid reason for BSV to raise the cap. fees of the big blocks will keep miners going.
patents and such is long way away form v 0.1 bitcoin.....
difficult decisions ahead, way over may head as an ex gold addict.


edit:
If he does not file for patents others will
https://thenextweb.com/hardfork/2019/03/13/data-china-is-patenting-all-the-blockchain-tech-despite-banning-cryptocurrency/

Yes. If you don't like big blocks because of [insert fluffy reasons here], then what you eventually end up doing is you have to keep the mining subsidy going on forever. Which means inflation, dolled out by the central bank (aka centralised developers, lobbied by the large miners). How is this any different from our existing central banking system? Oh right. You successfully replaced central bank economists with developers who have no background or expertise in managing and economy.
That will surely work better than the old system of money that we had. Surely. /sarc

So which is MORE centralizing?
A competitive environment of miners who fight to earn the most fees with bigger block handling being a competitive EDGE, building data centers, finding cheaper ways to source electricity or cheaper labour, or lower power ICs....without any limit on the transnational processing volume of the network.
OR
a bunch of neckbeard developers/cypherpunks who control the protocol to hide their digital numbers away from the law (corruption), and printing ponzi-coins to sell to miners (banks) whose only goal is to dump it into the brainwashed public as soon as they can to stay ahead of the inflation curve?

I know one of those situations sounds a heck of a lot like the existing monetary system, where nepotism and how much you make is determined to how close to the source of inflation you can position yourself, and that most changes are made via lobbying and not proof of WORK.

Wake up sheeples.

 

[Norway]

Hmm, it's not an edge case, it literally happens ALL the time. I've just restarted my btc node with -debug=mempool: I'm receiving at least 1 txn/s in inverted order (just check the timestamps below).

It doesn't require an "attack". An honest node generating dependent transactions and sending them *in order* will probably result in inverted order in a bunch of other nodes.

But keeping it real: what about my argument that BTC (even 0.1) and BSV don't store history any better? All bitcoins do sort transactions when creating block templates.

2019-04-02T04:04:09Z AcceptToMemoryPool: peer=6: accepted 8ca76b5ccd194a89c585cf123ab62ffde9600030c1db15176fbe383646ec3e04 (poolsz 3488 txn, 18171 kB)
2019-04-02T04:04:09Z  accepted orphan tx fb89b26a60de1d07ef35de2bc9283d09a6c8ca895d55d7a733c5647adb792dfb
2019-04-02T04:04:09Z stored orphan tx 787f9e54a7b1c3b42cf3f35981287ce6e1a4db89a5a8408e145e3adebae8f24a (mapsz 31 outsz 40)
2019-04-02T04:04:09Z stored orphan tx 308c8da967368360d3ea9d5f4dd60120dc8a634cc4f5a4af9480a31af2ef98c0 (mapsz 32 outsz 41)
2019-04-02T04:04:09Z stored orphan tx 1b7eb1d03855defdcc7633a2286c19566c708dde5e7bbac419cd7311d6ed96eb (mapsz 33 outsz 42)
2019-04-02T04:04:09Z stored orphan tx 40a3573ff84b6c555b5042ba2387cdd4949b5d6585e2cb2f4a9f408500ecf717 (mapsz 34 outsz 43)
2019-04-02T04:04:09Z AcceptToMemoryPool: peer=6: accepted 5b2986433b78a28661417705346ba4aca2f1e475cd108de0f8565aa249283055 (poolsz 3490 txn, 18173 kB)
2019-04-02T04:04:09Z  accepted orphan tx 1b7eb1d03855defdcc7633a2286c19566c708dde5e7bbac419cd7311d6ed96eb
2019-04-02T04:04:09Z  accepted orphan tx 787f9e54a7b1c3b42cf3f35981287ce6e1a4db89a5a8408e145e3adebae8f24a
2019-04-02T04:04:09Z  accepted orphan tx adec5aba419f20570d3976864619863e126334418a14ef1fefac3d1194fb1eba

What's the problem?
[doublepost=1554180008][/doublepost]Bitcoin (BSV) is going forward. We are not waiting for anyone. Keep up or stay behind.
[doublepost=1554180356,1554179496][/doublepost]nChain and CSW took charge. From my perspective, Satoshi Nakamoto came back from the shadows to set things straight. And it's working. Everything else is fluff.

 

[cypherdoc]

short squeeze.

 

[shilch]

Your point? This block has already been accepted into the blockchain and is historical for all Bitcoin*. Probably for more POW than had even been applied to the chain up to that point.

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

 

[freetrader]

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.

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

 

[sickpig]

So it's not a restoration of the timestamps a chronological order represents

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