[Bitcoin-ml] Flexible Transactions are canonical

[Tom Zander]

On Friday, 8 September 2017 11:30:24 CEST Tomas via bitcoin-ml wrote:
> I am sorry, but that is not what canonical means. A format has a
> canonical form if there is only one way to represent the same logical
> information.

The logical information is the information that generates a certain hash and 
signature.
So canonical is *exactly* the right description. Because its signed you 
can't change any single byte. And that's the exact  definition of canonical.

>  (In that case *every* format would have a canonical form!)

No, because you can have an unsigned v1 transaction where you swap outputs 
and nothing breaks.
So current unsigned transactions are not canonical.


I'm repeating my previous email, because you are repeating your arguments I 
already countered in previous emails.
I'll try to explain in more detail, can I ask you to spend time following my 
arguments before you reply with the same questions?

Bottom line is that you are talking about unsigned transactions.
Unsigned transactions have no canonical form. Just like a draft email has no 
canonical form. You could write it out in a dozen different encoding, for 
instance.

The process of signing a document or transaction will turn a non-canonical 
data format into a canonical one.
And Flexible Transactions are canonical, the moment they are signed.
Exactly like current v1 transactions.

> There isn't
> suddenly a canonical form when you sign it; there are still multiples
> ways to construct the same logical transaction, each of which would
> yield a different a byte sequence, different signature and different id.

The signing makes it canonical, because you break the signature if you 
reorder anything.
Realize that you can reorder a v1 transactions outputs and the exact same 
happens.

> Consider for instance tooling that uses a SQL back end to store its
> information (like http://blockchainsql.io/). Currently they can
> reconstruct every transaction's byte sequence from the data.

Sounds like they misunderstood the concept of “data warehousing”.
You don't store 100% of the raw data in your warehouse, you refer to 
upstream if you want the raw data.
Storing the entire blockchain in a SQL database is not scaleabe and 
ultimately a bad idea.

What happens when people add a new tag in FlexTrans? For instance  a tag 
where wallets like blockchain.info can say they generated this transaction 
and miners that are keen on growing the industry recognize that those kind 
of wallets are essential for growing the industry. So they give a weekly 
reward spread based on how many transactions a certain company created.
Will you say that adding tags like this or any other also breaks “canonical” 
format, because its some information your database doesn’t know about?

No, your examples like the CTransaction format and your SQL database are 
filtered versions of the canonical format. They are not meant to enable a 
round-trip.
A signed transaction is read-only information, the entire approach of 
interpreting it and then writing it out expecting a 100% same output is 
broken by design.
Don't round-trip it if you want the original. Use the original.


ps. data-warehousing of blockchain data is a research topic related to the 
Bitcoin Classic project and some more sane approaches are being worked on.
-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel