Gold collapsing. Bitcoin UP.

[Norway]

Attaching it to Bitcoin and trying to extract meaningful results from it is.

No, that's just an unfounded claim. Transactions don't happen when a block is found. The history is real and useful for accounting.

That's the last I'll say on it.

You have said that before...

 

[attila]

Attaching it to Bitcoin and trying to extract meaningful results from it is. That's the last I'll say on it.

The SR and GR theories is about TIME.

Bitcoin is the first distributed time keeping system that solves the Byzantine Generals problem.

You can't be serious that I'm just merely "attaching it to Bitcoin"?

The whole thing is inextricably linked.

You don't get to pick and choose your math and physical systems theorems and ignore the ones that don't fit your narrative.

Well you can, but you are about to see how BCH cannot work for a time-keeping system (and therefore is infeasible as CASH). You will also see many other properties play out in Bitcoin (BSV) that are impossible in BCH.

You will be unable to ignore the consequences reality of the situation soon.

 

[cypherdoc]

Is this true?
Well, it certainly is true that https://bsvexplorer.io shows Error: Not found

sad lol :

 

[Richy_T]

You have said that before...

I said I wasn't going further with it. You made replies which demanded a response. It wasn't really taking it any further but now that really was it. I may still weigh in on actual Bitcoin topics like transaction ordering and the like though.

 

[freetrader]

Just saying there is still a problem.

[doublepost=1553826950][/doublepost]If block explorers can't stay up during this testing on the operational system, then what will happen to ordinary businesses. Yay unscheduled service interruptions.

Expansion of capacity in this way doesn't seem a stable approach to operating a financial system that needs to be reliable. Make noise about "locking down the protocol" all you want.

 

[Richy_T]

You will be unable to ignore the consequences reality of the situation soon.

That's fine. I'm not saying one system of block ordering is better than another. In fact, to me, they are logically equivalent and an implementation detail. It will be interesting to see which wins out (assuming other things don't come in to play first).

 

[Norway]

I said I wasn't going further with it. You made replies which demanded a response. It wasn't really taking it any further but now that really was it. I may still weigh in on actual Bitcoin topics like transaction ordering and the like though.

Well, your defence of LTOR is crushed with physics now.

 

[attila]

That's fine. I'm not saying one system of block ordering is better than another. In fact, to me, they are logically equivalent and an implementation detail. It will be interesting to see which wins out (assuming other things don't come in to play first).

I'm curious -- how is it "logically equivalent" if you had to sort through the comments on this forum in lexicographical order versus causally ordered? More energy and time would need to be spent in finding and knowing what to reply to!

 

[Richy_T]

Well, your defence of LTOR is crushed with physics now.

Lol. Nice try.

 

[Norway]

Lol. Nice try.

Well, I don't think anyone who's been reading here believes your alternate reality where all transactions in a block happen at the same time.

 

[Richy_T]

More energy and time would need to be spent in finding and knowing what to reply to!

Perhaps. And? In either case, each block must consist of valid transaction based on the state of balances at the processing of the previous block. This is the salient definition of a block.

I just went looking for Norway's original posts of your tweets just to check my sanity. Do you know how I got there? It wasn't searching chronologically through historical posts, it was by following links which referred to previous posts. Reddit doesn't sort posts chronologically but presents them in a tree based structure (though it may .allow chronological sorting too). Do you think it matters if this post is stored in an "earlier" sector on the hard drive of the server this forum is running on? No. Because logically, it's presented by the database in an easy-to-retrieve manner.

Let's say we have a block with two transactions, T->C and C->A.

So we could have two potential ways of storing this in a block. "Chronologically",

T->C
C->A

And lexigraphical (I'm not fond of "canonical")

C->A
T->C

So, realistically, other than some optimizations, what is the real difference? Does the second one imply that T->C comes after C->A? No, obviously not. Any process running through the block can see that C->A is not satisfied and defer processing until later after T->C has been processed.

Indeed, if you are running parallel processing on the block, you may not be able to predict which transaction is handled first anyway so you *have* to build in the ability to defer processing of a transaction. The alternative is to force a strict serial processing of the block which will cause an unnecessary bottleneck.

This is not to defend LTOR. I think was not justified to force it into the fork as it was so please don't come at my motivations from that angle. I am just with @rocks in that I don't see the block ordering as being important from a Bitcoin Whitepaper perspective.
[doublepost=1553829347][/doublepost]

Well, I don't think anyone who's been reading here believes your alternate reality where all transactions in a block happen at the same time.

Do you have Rocks on ignore? And you presume to talk for everyone here? That's pretty ballsy.

 

[Norway]

Do you have Rocks on ignore? And you presume to talk for everyone here? That's pretty ballsy.

I don't have Rocks on ignore. It's not relevant. And I don't presume to talk for everyone here. That's a strawman invented by you. My sentence was very short, you should be able to understand the content, but I can split it up in smaller parts. Do you understand what "I don't think" means?

 

[Richy_T]

Perhaps you mean to imply that he hasn't been reading here then. Quite a feat considering his posts. Do you understand what "anyone here" means?

I know what "I don't think" means. So evidently the implication is that your thinking is compromised. I can go with that.
[doublepost=1553830989,1553830364][/doublepost]Simple logic time.

a) A transaction is not an actual transaction until the block it's in is solved (which is later accepted by the network).
b) A block is solved at a specific instant in time.
Therefore
c) All transactions in the same block become actual transactions at a specific instance in time.

 

[attila]

Does the second one imply that T->C comes after C->A?

No. It implies additional energy needs to be spent by future users of the data (that expect the chronology intact)

Indeed, if you are running parallel processing on the block, you may not be able to predict which transaction is handled first anyway so you *have* to build in the ability to defer processing of a transaction.

Who's doing parallel processing now? And what does post-processing of tx's in a block have to do with storing them in chronological order?

I am just with @rocks in that I don't see the block ordering as being important from a Bitcoin Whitepaper perspective.

It mentions "chronological" and "history" a few times. If it's violating the causal order, then it nessarily violates the chronological order, by definition.

If you do not see it violating the definition of Bitcoin, that's fine. But it's factually important and relevant because:

a) Sub-10 minute accounting practices are more difficult/cost more energy
b) You do not have cryptographic/tamper-proof evidence of chronological order (backed by PoW)
c) Apps that depend on causal ordering being received now require extra logic and also more energy
d) Chronological ordering is no longer possible in sub-block precision.
e) We lost valuable network topology information about what each miner sees and when they saw it.

 

[Richy_T]

Who's doing parallel processing now?

BU has been looking into it for quite a while, actually.

 

[Norway]

@Richy_T
I meant what I said. Your nitpicking is not convincing.

Your response to attila showed that you don't understand that important historical information is lost with LTOR.

Example:
Let's say I lend you 1 bitcoin. You pay it back before a block is found, but from a different unspent output.

BSV: My accountant can provably see that i lended you money and took on risk before I was paid back.

BCH: My accountant can not see who lended money from who.

 

[attila]

a) A transaction is not an actual transaction until the block it's in is solved (which is later accepted by the network).

What? Yes it is an "actual transaction". What do you mean by "actual"?

Are you're saying that when I query a mempool transaction that I'm querying a ghost or something "not actual"?

b) A block is solved at a specific instant in time.

When a block is solved does not matter. There is no such thing as "exact time". This "specific instant" varies from the inertial frame of reference of the miners receiving the transaction. There is no such thing as "specific instant". We've pointed this out almost a dozen times here. It's mathematically and logically non-sensical to say this.

c) All transactions in the same block become actual transactions at a specific instance in time.

False. They were "actual" transactions before. They are now simply backed by some amount of PoW now and a certificate exists of that fact (in the form of the block hash).

There's no "specific instance in time". This makes no sense when it comes to the context of creating a timestamp server from first principles. There is no outside time and there is no 'specific instance of time' that all observers agree upon. This is the great mathematical insight by Einstein.

 

[Richy_T]

No. It implies additional energy needs to be spent by future users of the data (that expect the chronology intact)

And that's a valid reason to prefer ttor (or whatever) over ltor. It doesn't invalidate my point in any way, however.

a) Sub-10 minute accounting practices are more difficult/cost more energy

I think you'll need to explain to me how it makes any difference whatsoever.

b) You do not have cryptographic/tamper-proof evidence of chronological order (backed by PoW)

It's about the same either way. You do know that a miner may receive transactions out of order from when they were created, right? All that's required is that all transactions within a block are valid. It doesn't really matter what order they were received in or when.

d) Chronological ordering is no longer possible in sub-block precision.

See my previous answer.

e) We lost valuable network topology information about what each miner sees and when they saw it.

Only for the miner who actually mined the block (and any orphaned siblings). I'd question exactly how valuable that is but I'm sure someone has a use for it.
[doublepost=1553832273,1553831580][/doublepost]

What? Yes it is an "actual transaction". What do you mean by "actual"?

One that actually counts. One that transfers funds from one entity to another in a recorded and permanent way.

I have generated "transactions" on my hard-drive that have never seen the network, some still valid but they mean nothing. Transactions fell out of the BTC mempool when congestion was around and they mean nothing. Luke-jr claimed there was no need to increase the block size because he could generate large number of off-chain transactions to raise the TPS rate of BTC. They don't count either.

Are you're saying that when I query a mempool transaction that I'm querying a ghost or something "not actual"?

The nomenclature is unfortunate in that we name candidate transactions the same as actual transactions. This is why I qualified the word the way I did. Yes, transactions in the mempool aren't actual transactions until they are confirmed in a block.

This "specific instant" varies from the inertial frame of reference of the miners receiving the transaction.

I promised a dear friend I'd leave this alone but I'll just say I'm giggling a bit at this.

False. They were "actual" transactions before. They are now simply backed by some amount of PoW now and a certificate exists of that fact (in the form of the block hash).

OK, stop thinking of a transaction in terms of the broken Bitcoin definition which is a string of bytes representing the intent to record a value in a distributed ledger transferring funds between a number of addresses and think about what a transaction is in the real world. It is when something is actually transferred from one entity to another. A transaction has not occurred on the Bitcoin ledger until a block has confirmed.

 

[attila]

And that's a valid reason to prefer ttor (or whatever) over ltor. It doesn't invalidate my point in any way, however.

True, but it's a strong argument against LTOR.

I think you'll need to explain to me how it makes any difference whatsoever.

More energy/time cost means that it results in:

- Lower profits
- More bugs
- More complexity
- Less time to do other things

It's about the same either way. You do know that a miner may receive transactions out of order from when they were created, right? All that's required is that all transactions within a block are valid. It doesn't really matter what order they were received in or when.

How is it about the same either way? In one case the order is backed by PoW and in the other case it's backed by 0 proof of work. Your accountant or software that parses LTOR could have a bug and you wouldn't be able to trivially verify that it's correct without having yet another layer of software.... (which itself then needs more verification)

See point above about more time/cost. Also, it will be you (and me) explaining to the IRS "what really happened, in what order" when it comes time for tax and audit. Imagine how painful this will be with TB sized blocks and a corporation at scale doing 100's or 1000's of transactions each block.
Sure you can write software (that will have bugs) that can produce a chronological timeline.

Only for the miner who actually mined the block (and any orphaned siblings). I'd question exactly how valuable that is but I'm sure someone has a use for it.

Of course it's important to those that mine the blocks. That's what I stated above (ie: that the miners get valuable diagnostic information about their perspective of the network). In fact, it was important enough that 100's of millions of dollars were spent defending it by big miners.

One that actually counts. One that transfers funds from one entity to another in a recorded and permanent way.

I have generated "transactions" on my hard-drive that have never seen the network, some still valid but they mean nothing. Transactions fell out of the BTC mempool when congestion was around and they mean nothing. Luke-jr claimed there was no need to increase the block size because he could generate large number of off-chain transactions to raise the TPS rate of BTC. They don't count either.

The actual transaction exists before it is mined into a block. See CSW's recent posts on off-chain transactions for succession planning with nLockTime. They certainly exist in a very real sense and have the ability to alter the future.

The nomenclature is unfortunate in that we name candidate transactions the same as actual transactions. This is why I qualified the word the way I did. Yes, transactions in the mempool aren't actual transactions until they are confirmed in a block.

Replace the word transaction with 'event'. That's what they are in physical terms.

There are events backed by PoW or not backed by PoW. Tx's with PoW behind it or not. Confirmed or Unconfirmed.

OK, stop thinking of a transaction in terms of the broken Bitcoin definition which is a string of bytes representing the intent to record a value in a distributed ledger transferring funds between a number of addresses and think about what a transaction is in the real world. It is when something is actually transferred from one entity to another. A transaction has not occurred on the Bitcoin ledger until a block has confirmed.

The entire universe is the transfer of information (ie: energy). EVERYTHING. This is a known fact. Not a debate.


>between a number of addresses and think about what a transaction is in the real world.

This is the real world as long as information and energy can be impacted by the past light cone or then in turn impact the future light cone.

>It is when something is actually transferred from one entity to another.

INFORMATION and INTENT is transferred (ie: the only things that can be transferred in the universe). See CSW's post on 'Succession Planning' to see how off-chain tx's impact the "real world"

>A transaction has not occurred on the Bitcoin ledger until a block has confirmed.

Yes, but no one was debating that a transaction that's not confirmed is also confirmed. Only confirmed transactions are in the ledger -- of course. But the transactions exist prior to being confirmed (ie: prior to a block being accepted by network consensus)

 

[Richy_T]

Ugh. Hate that this forum won't let you quote the last post. Hold on...
[doublepost=1553834532][/doublepost]

True, but it's a strong argument against LTOR.

It's certainly an extremely strong argument for not rushing to it.

More energy/time cost means that it results in:

- Lower profits
- More bugs
- More complexity
- Less time to do other things

I mean specifically the sub 10-minute accounting thing.

How is it about the same either way? In one case the order is backed by PoW and in the other case it's backed by 0 proof of work.

No. Both blocks are confirmed with the same amount of proof of work. I am having trouble imagining what issue you would have with the IRS. "This transaction was in block #890023 which has a timestamp of 13 Jul 2020 13:12:00" about covers it. I don't see how TTOR (what would you prefer it called?) affects that.

Of course it's important to those that mine the blocks.

I mean that's all the information you get is about the miner that mined the block. All the other blocks other miners were working on are just abandoned.

They certainly exist in a very real sense and have the ability to alter the future.

Only if they get mined into a block. Offchain processes can do things with them, of course but we are specifically talking about blockchain stuff.
[doublepost=1553834968,1553833971][/doublepost]Let's say I have, uh, let's not be stingy, 3000 BSV in address A. I construct and sign a transaction for 2000 BSV from address A to address B. I also construct and sign a transaction for 2000 BSV to address C.

Are these both transactions? In Bitcoin nomenclature, sure. They are both even *valid* transactions. Yet if I transmit both to the network, someone is going to be disappointed. I think we can agree there.

So the issue (on this point) seems to be that you don't like my nomenclature. Perhaps we could compromise and call confirmed transactions "transaction events". The main issue I have is that "transaction" carries connotations that are actually not present with Bitcoin "transactions".