Should members of Bitcoin Unlimited be expelled when they no longer follow Articles of Federation?

[attila]

@freetrader

if I could under current circumstances, as his irrelevant content posted in these threads just seems like phishing to be "cEnSorED" to score some political points.

Everyone seeks "political points". That's the Human currency (attention and value). We are all doing that.

"Irrelevant" posts? The topic is: "Should members of Bitcoin Unlimited be expelled when they no longer follow the... ?"

What could be more relevant than talking about the focus of the organization and how the organization's members are focusing on something that is objectively not Bitcoin? It is relevant that BCH is by definition not Bitcoin.

Maybe someone will find a way to provide "computational proof of the chronological order of transactions." for BCH at scale. I don't see how it's possible...but someone smarter than me might be able to explain it.

I hope someone will attempt to address the substance of my claim instead of merely posting (truly off-topic posts) about how to suppress dissent by explaining the functionality of the "ignore" button and whether my post should be "deleted".

 

[Jonathan Silverblood]

But, the bitcoin in the whitepaper doesn't offer any computational proof of the chronologial order of transactions either, so why is that important to you?

The first-seen rule means that two nodes can who see a different order is both right until a block is mined, and when a block is mined, an objectively wrong order can be stored on the chain.

 

[attila]

@Jonathan Silverblood

Yes it does. The transaction order inside and between blocks is in chronological order.

"an objectively wrong order can be stored on the chain."

There's no such thing as an "objectively true" order just like there's no such thing as "objectively wrong". Your statement implies there is something called "true time". This is a fallacy.

It's an illusion and proven false with Special and General Relativity over 100 years ago.

The *blockchain transaction order* is the time, you cannot appeal to "true time" or the "real objective time" since we are trying to build a p2p distributed timestamp server with Bitcoin (as defined in the WP). It would be circular reasoning to appeal to the "true time" where the "true time" you are referring to is not backed by PoW.

The requirement for "chronological" is that any causally related events are laid out in left-to-right order (or vice versa). The other non-dependent events can take any order because time has no significance when not bound to a frame of reference (or bound to a causal chain of events)

It is impossible to do cash accounting for BCH at sub 10 minute increments at scale (10 TB sized blocks, 1000's of transactions from accounts paid/received in sub 10 minute intervals).

Cash use-case is infeasible for BCH because the lowest granularity is 10 minutes. Your accountant cannot produce a timeline of transactions at scale and provide a tamper-resistant proof that the accounting software [that reconstructed the causal/chronological order] is bug free and has the ordering correct.

Whereas in Bitcoin, you can just verify in O(N) time that the transactions are in correct order and trivially check the hash to confirm it is correct.

What does the algorithm look like to generate accounts paid/received for 5,000 tx's within a 10 minute window where some have parent-child relationships and some do not? How can you *prove* that the order presented by your software is actually correct?

It's not possible. And as such, it fails to meet the requirement of Bitcoin, as defined in the protocol implementation and the definitions laid out in the WP.

 

[Jonathan Silverblood]

So you're saying that if me and my friend are standing next to eachother, and I send a transaction. One minute later, he sends a transaction.

Then due to network propagation issues the block ordered his transaction first, then it actually happened first due to special relativity?

I'm all for weird physics, but bitcoin isn't a physics experiement, it is peer to peer money for the world. observers can in many cases point out objectively incorrect orders getting into a block.

And even if you'd argue that TIME is relative and has nothing to do with it since we're making a timestamping server, then CTOR has no practical difference to any other sorting order since the time is defined per-block. There was never any guarantees with regard to in-block ordering.

 

[attila]

@Jonathan Silverblood

"Then due to network propagation issues the block ordered his transaction first, then it actually happened first due to special relativity?"

That's not what I said.

You are standing in-front of your friend and you have direct experience and direct "Proof of Work" that you know the correct order.

However, your accountant who is generating a timeline of the 5,000 transactions that happened globally distributed in a 10 minute window does not have the luxury to know except form analyzing the sequence of transactions themselves.

That's the entire point of having a distributed timestamp server that solves the Byzantine Generals Problem. To organize reliable communications in a timeline across great distances.

"I'm all for weird physics, but bitcoin isn't a physics experiement, it is peer to peer money for the world. observers can in many cases point out objectively incorrect orders getting into a block."

Bitcoin is a physics experiment. Eating my sandwich is a physics experiment. I'm not being facetious with this. This is how physicists talk. These are all physical systems and we are using the system for something (ie: it's a physics system/experiment)

You are attempting to discount physical properties and information theoretic concepts by saying "it's not a physics experiment". Let's stick to the facts.

And even if you'd argue that TIME is relative and has nothing to do with it since we're making a timestamping server,

I'm not arguing TIME is relative.. Einstein proved it mathematically - 100 years ago. This is now an accepted fact of the nature of all events in the universe.

Time being relativistic has everything to do with creating a time-measuring device such as Bitcoin (distributed timestamp server).

"then CTOR has no practical difference to any other sorting order since the time is defined per-block"

Time is not defined per block. The transaction order itself is the measure of time. The "timestamp" (not to be confused with "time") is a convenience field at the block level to anchor the set of events at that point. Inside the block the "time" is block.timestamp + i (where i is the index of the i'th transaction in order)

Furthermore, there is a practical difference. Basically it now takes:

a) More energy for users of the network to reconstruct the causal order
b) More time/cost for users to construct a timeline
c) There is no trivial to verify computational proof that the produced timeline is correct

"There was never any guarantees with regard to in-block ordering."

Yes there is. Namely that the child transactions follow their parent inputs in causal (ie: chronological order). This is a partial chronological ordering to be specific. However it is a chronological order.

But if we extend out to remote distances, then we can actually take it to be full chronological order because time has no meaning when not anchored to a frame of reference or another set of causal events.

What does it mean for BCH?

As a large corporation that has accounts paid/received...will not use BCH because they need a timeline of what happened and a tamper-resistant proof that the timeline is correct. Another blockchain is needed to record the receipts of the BCH transaction.

The reason my statements may seem "way out there" or surprising is for the same reason that people in general are surprised (and outraged sometimes) when they hear about the implications of the nature of SR and GR.

There is no such thing as "true" time or "real" time. This is a non-sensical notion. But it was a useful approximation base case for our evolutionary past where our direct experiences were non-relativistic --- and our technology did not take advantage of this property of space and time.

What matters in spacetime is there is a causal relation between events in spacetime. The exact measure of time does not matter -- what matters is the relationship between these events.

Transactions are events just like any other.

You cannot just pick and choose which mathematics and information theorems you want to apply to a distributed computing system such as Bitcoin.

Well, one can try to ignore reality. But then you end up with a situation where it's impossible to form a timeline of events for an accounting system at scale. And you end up with a scenario where complex, potentially buggy software will need to be created just to recover "who was paid and when".

See:
http://www.gutenberg.org/files/5001/5001-h/5001-h.htm
https://en.wikipedia.org/wiki/Light_cone

 

[Griffith]

Time is a social construct.


> As a large corporation that has accounts paid/received...will not use BCH because they need a timeline of what happened and a tamper-resistant proof that the timeline is correct. Another blockchain is needed to record the receipts of the BCH transaction.

this is false. time is identified per block. transactions don't hold time data and don't form a timeline themselves without the assistance of being inside a block. you can easily use the other rules that govern valid use of the blockchain to, with little effort, reconstruct the order of which transactions happened first in relation to their parents/children inside a given block. Just because the order isn't done for you doesn't mean it is now impossible to distinguish. it is actually trivial to distinguish

LTOR might have been rushed and is useless right now due to lack of optimizations actually using its ordering to their benefit *cough* abc (this is a joke aimed at freetrader) *cough* BU has graphene that utilized LTOR ordering now *cough* but it doesnt break anything

 

[attila]

@Griffith

"Time is a social construct."

Everything is socially constructed if you want to play that game. But thankfully we don't have to because It's a sociological "concept" that has no predictive power and is self-contradictory.

Ask yourself this: Is the statement "Time is a social construct" itself a social construct? Or are you making an objective statement of reality?

Simply put, the social constructionists are wrong. It has no predictive power, and it's self contradictory.

Quote:

"Rather, there can be "multiple realities that compete for truth and legitimacy.". Now ask yourself this... is that a single view of reality they are putting forth? It appears like they have made an objective statement of a SINGLE reality of the statement of "multiple realities that compete for truth and legitimacy." - https://en.wikipedia.org/wiki/Social_constructionism

This is a contradiction.

Social construction theory is a great source of human confusion. See: https://en.wikipedia.org/wiki/Social_constructionism#Criticisms for the "nail in the coffin".

MOVING ON...

"time is identified per block. transactions don't hold time data and don't form a timeline themselves without the assistance of being inside a block."

a time(stamp) is identified with a block. But transactions in order form a timeline whether they are in a block or not. Naturally parent-child transactions are in a timeline. The minimum increment of time is the Planck Time between 2 transactions.

"you can easily use the other rules that govern valid use of the blockchain to, with little effort, reconstruct the order of which transactions happened first in relation to their parents/children inside a given block"

How? We have 10TB blocks and 1000's of tx's in a 10 minute slice. What's the algorithm? I've provided the algorithm above for the O(N) verification of the order of tx's in Bitcoin. How to do in in BCH?

By the way, just because you can reconstruct a timeline, does not change the fact that it's not in chronological order (because you must spend energy and cost to recover the chronological order).

"Just because the order isn't done for you doesn't mean it is now impossible to distinguish. it is actually trivial to distinguish"

Great to hear! What's the "trivial" algorithm to do it. I've provided the Bitcoin algorithm above in linear time that would be sufficient evidence and acceptable at scale. How will you do it with BCH to *prove* that the timeline you construct is correct?



Edit: removed para and fixed typo

 

[Griffith]

> Great to hear! What's the "trivial" algorithm to do it. I've provided the Bitcoin algorithm above in linear time that would be sufficient evidence and acceptable at scale. How will you do it with BCH to *prove* that the timeline you construct is correct?

Do you not know that transaction inputs are the outputs of their parents? That u can simply lookup the txid of the parent of an input using the information in the input which is inside of the child transaction?

for example: if you want to find the txid of a parent for a single input tx Y (its parent should be X) and X is also in the same block as Y you would simply iterate through the vtx of a block looking for a txid X which is stored in Y in the field input.prevout.hash.

this would be the exact same way you would find X in the block if the transactions where in a chronological order btw. and yes. its linear time

 

[attila]

@Griffith

"Do you not know that transaction inputs are the outputs of their parents? That u can simply lookup the txid of the parent of an input using the information in the input which is inside of the child transaction?"

Yes, and that's why it's no longer chronological ordering (because the order of inputs from parents to children are not respected). Obviously you can reconstruct some chronological order, but the order will not be backed by PoW.

Sure you can spend more time/energy/resources to recover a chronological order.

"For example: if you want to find the txid of a parent for a single input tx Y (its parent should be X) and X is also in the same block as Y you would simply iterate through the vtx of a block looking for a txid X which is stored in Y in the field input.prevout.hash"

What is the time/space complexity of this algorithm? Remember, we imagine 10TB blocks with 1000's of tx's for various addresses for a corporations accounts received.

What if you want to construct a timeline of multiple accounts and their relation in time to each other?

 

[Griffith]

i said its linear time to find the parent in the line below you stopped quoting. please at least read the whole response.

It is the same time complexity to check if a parent is in a given block regardless of the ordering.

I do not know why you think some tx ordering schemes makes the POW of the block less valid than other orderings. Your entire backed by POW argument does not make sense.

 

[attila]

@Griffith Linear time?

We have a list of size N of the transactions in a block.
How can you sort these N transactions in linear time? Sorting a list is O(n lg n).

Backed by PoW means we can trivially check that the timeline is correct and the order has not been tampered with by accident or malice.

How does your algorithm produce the correct order? Who's software are you trusting to produce this timeline?

Also, how do you know what the "non-dependent" transaction order is supposed to be when their inputs could be mixed with other addresses that are not your own?

I'll provide the algorithm for verifying transactions in Bitcoin, if you have time, please provide the algorithm for BCH.

tx_history = get_timeline_for_address(block, address) {

timeline = []
for (tx in block) {

if (tx.address == address) {

timeline.append(tx)​

}​

}
return timeline​

}

tx history now contains the chronological/causal order of transactions for an address, backed by cryptographic signature proving it is correct timeline of events.

Linear time, simple and can be verified to be correct trivially by checking the block hash

 

[Griffith]

What you are complaining LTOR doesn't do, the last transactions sorting did not do either. At no point do you ever have a timeline of transaction order outside of the relation to their parents and their children. At this point i am unsure if you understood how the transactions in the legacy ordering were ordered.

In the original ordering if the block contained 3 transactions (not including the coinbase) and none of them spend the outputs of the other then
123
132
321
312
213
231
were all valid orderings of the transactions in the block. the only timeline you are guaranteed is that they were all within the block. which tx of the 3 was generated first is not stored in the block information.

 

[attila]

@Griffith

"What you are complaining LTOR doesn't do, the last transactions sorting did not do either. "

LTOR does not respect the parent-child relationships. That's the only thing I'm complaining about. This is a necessary (and actually sufficient condition when taken with Special Relativity) to be considered "chronologically ordered'.

"At no point do you ever have a timeline of transaction order outside of the relation to their parents and their children."

Isn't this true for all events, in all distributed systems? Namely that the causal order is respected. Time means nothing outside of causality.

"were all valid orderings of the transactions in the block. the only timeline you are guaranteed is that they were all within the block. which tx of the 3 was generated first is not stored in the block information."

Yes, but only 1 of them has a computational proof so it's trivial to verify. Furthermore, only in the base case will it take linear time in your example. Which will likely be the minority of cases at scale for a large organization.

How would you be able to generate a chronological order for N organizations that are transacting with K transactions in a 10 minute window? Let block sizes be 10TB and let N = 10 and K = 100,000

It's going to be a non-trivial algorithm to resolve all ancestors of each input and recover the causal ordering.

The only timeline properties we want guarantees of (like the Bitcoin paper states) is:

1) causal relationships between parent-child are satisfied
2) the timeline is trivial to verify and has PoW backing the solution

Point 1) is a necessary condition to be chronologically ordered.

 

[Griffith]

> LTOR does not respect the parent-child relationships. That's the only thing I'm complaining about. This is a necessary (and actually sufficient condition when taken with Special Relativity) to be considered "chronologically ordered'.

so let me get this straight. your complaint is that LTOR which is not a chronological ordering, is not a chronological ordering?


> Yes, but only 1 of them has a computational proof so it's trivial to verify. Furthermore, only in the base case will it take linear time in your example. Which will likely be the minority of cases at scale for a large organization.

what computational proof? when they are packed into the block the order is up to the miner

 

[attila]

@Griffith

"so let me get this straight. your complaint is that LTOR which is not a chronological ordering, is not a chronological ordering?"

My complaint is that BCH is not "Bitcoin" as defined because it lacks the ability to have "computational proof of the chronological order of transactions".

My additional complaint is that I cannot use BCH as cash because it's non-trivial to reconstruct a timeline for auditors and accounting purposes at scale.

"what computational proof? when they are packed into the block the order is up to the miner"

The computational proof defined in the white paper. The miner is not free to decide to violate the parent-child ordering rule. If you violate that, then it's impossible to have chronological ordering of transactions within the block.

The non-dependent transactions that are not related by parent-child do not matter, because those are from the miner's frame of reference and as such can be in any order and still be considered chronological. There is no "true" or "real" time with Special and General Relativity. That is a fallacy.

The only thing that's required to maintain chronology is that causality is preserved.

 

[Griffith]

I acknowledge that you read the whitepaper, but understanding what it says is something different entirely. I will try to explain it to you

The timestamp server it is talking about is blocks. The blocks timestamp what transactions were committed to the blockchain at what time using the proof of work that was needed for a valid block to be mined. The depth since a transaction was committed is what we generally refer to as confirmations. 0 being not yet committed, 1 being committed in the block tip, etc. What that sentence in the whitepaper is saying is "we can solve the double-spending problem by using block timestamps and the POW needed to mine those blocks to generate computational proof of the chronological order of transactions as they are committed to the blockchain"

this is why 0-conf at this time can be dangerous. we have not solved the problem of preventing double-spending with the timestamp server because these transactions are in the stage before they are stamped with a block time (by being packed into a block).

The entirety of your complaints seems to stem from a misunderstanding of what part of the blockchain is the timestamp server.

 

[attila]

@Griffith

I know what you are saying. I'm very aware of what you point out. That was my first level understanding too. But it's mistaken and shown to be incorrect just merely from definitions of the word "chronological".

"The timestamp server it is talking about is blocks."

No. It's talking about the entire Bitcoin system. Blocks are a fundamental part of the solution of course.

"What that sentence in the whitepaper is saying is "we can solve the double-spending problem by using block timestamps and the POW needed to mine those blocks to generate computational proof of the chronological order of transactions as they are committed to the blockchain"

No. It's not. You added that.

Are you aware of the implications of The Relativity of Simultaneity? http://www.gutenberg.org/files/5001/5001-h/5001-h.htm#ch9)

"this is why 0-conf at this time can be dangerous. we have not solved the problem of preventing double-spending with the timestamp server because these transactions are in the stage before they are stamped with a block time (by being packed into a block)."

Who said 0-conf is 100% safe? Nothing is 100% safe. But my argument has nothing to do with unconfirmed transactions. I'm not sure how this point is relevant to the claim that transactions within blocks are meant to be chronologically ordered.

"The entirety of your complaints seems to stem from a misunderstanding of what part of the blockchain is the timestamp server."

The entire system is the timestamp server. You cannot take away any part of it and have something that functions. The WP clearly says that Bitcoin is a distributed timestamp server. It doesn't say "The blocks are the only part that are concerned with time" or anything even remotely close to that.

I still have yet to see anyone provide an algorithm and analysis for recovering the chronological ordering of transactions in BCH. People just tell me It's "trivial".

 

[Griffith]

i didn't add anything, i was paraphrasing it so you might have an easier time understanding. I do not believe there is anything else i can do to try and clear your confusion. i tried but i am sorry.

i can explain it to you but i can't understand it for you

 

[attila]

@Griffith

1. Paraphrase (verb): express the meaning of (the writer or speaker or something written or spoken) using different words, especially to achieve greater clarity. - https://www.google.com/search?q=define+paraphrase

You just contradicted yourself by saying you "didn't add to it" you just "paraphrased" (which literally means "to add").

"I do not believe there is anything else i can do to try and clear your confusion."

I'm not confused. I provided a simple algorithm above to show a timeline of payments received that contains proof of the chronological ordering of transactions for an address within a block in Bitcoin.

You mentioned it was "trivial" to get the chronological ordering of transactions for an address in BCH. What's the algorithm?

 

[Norway]

Inside the block the "time" is block.timestamp + i

Thanks for being specific. This is what we'll use if our company build an accounting system for bitcoin (we are seriously considering this).

It's very clear to me that this can not be done on BCH.

I'll paste in my tweet here that explaines how BCH screwed up accounting with LTOR.


PS. I'm very disappointed in the ignore/censor attitude from many in this thread.