Topic: TX_CERT a protocol to certify a collectible using Bitcoin network (Read 546 times)

I did read most of OP, definitely not understanding everything, though.

This Q&A is nice, but I got a few questions:
- I checked your example transaction (https://blockstream.info/tx/c143e12484a975f4ba1fcc655dda1e864b3a545b0cfa37cfc65f17efc8d82f28?expand) -> How can a human (easily) read the info you want to convey from it (can you send  screenshot with explanation or something in that regard)?
- Trying to summarize what I think the workflow here goes and you can please elaborate on certain points:
   1. You create a physical object, the collectible. Do we now have any link to 2) on the object itself? A kind of key that refers to a transaction we are going to create on the blockchain?
   2. We now create a transaction using your protocol to certify the creation of the object and a public address (the creator's?) associated with the creator?
   3. Let's assume we now sell the collectible to someone else - How do we proceed? Create another transaction? Or let the buyer create a transaction? Do we use a key from the physical object to do so? If yes, how do we ensure, the key will not be re-used by someone that is not in possesion of the collectible anymore?
   4. Does any public information need to be provided outside the transactions on the blockchain for 3rd parties to verify the object and its current ownership status?

One more question: With this concept is it iNECESSARY to disclose all paid amounts if the item is sold and resold and so on? Is there a way to keep some kind of anonymity for byuers and resellers?

Lots of naive questions, just trying to at least give this concept a shot at understanding.

Thanks for your work, always amazes me when trust-systems are created without the need for a real person in the middle.

AS MJ said, probably not reasonable for the majority of people, though. The general problem with collectibles is trust in certain people. Most collectors are aware that (funded) crypto-collectibles are kind of in opposition towards what Bitcoin stands for.
I wonder if this can ever be solved without major tradeoffs (such as complex solutions that will never attrackt "simple" coin-collectors etc.).


Edit: I read some bitbollos response to MJ, but still would be nice if you can elaborate some of my questions again.

I found an interesting project:

[ANN - INFO] Project Icarus: The forum redemption story 🔐

There might be some interesting overlapping and it could be possible to collaborate for the success of both project.

This is the first TX_CERT transaction on the Bitcoin network:

https://blockstream.info/tx/c143e12484a975f4ba1fcc655dda1e864b3a545b0cfa37cfc65f17efc8d82f28?expand

It is the certification of the test piece (00/10) of this series:

https://bitcointalksearch.org/topic/available-gbg-block-erupter-glass-bell-0911-available-5439758

form my 1GBG1boyVmsdpqsfYHhY1mbDKdZ7TGKrEw address:

output 0.001 BTC to bc1q3zxvc590wsq3857hplrsrg4dagjs4u8m53hp3f (owner's address)
output 0.01099 BTC to 1GBG1boyVmsdpqsfYHhY1mbDKdZ7TGKrEw (change return)
OP_RETURN DATA: TX_CERT,GBG,Block Erupter 1,00/10

I suppose this system consumes a lot of space in the blockchain.

Let's remember that the blockchain is a precious asset, and that the OP_RETURN was
introduced precisely for the purpose of being able to write information in the blockchain
at the lowest possible cost.

your chain of "nested signatures" is very space-intensive
and I am also afraid that it is subject to possible easy spam attempts by
 malicious users.

But I find the basic idea very fascinating.


If you ask questions I can try to explain it better

Thats why we signature bind,
the signature can contain whatever data, a maker publicly releases said signature chain genesis, including a chain of custody signature message from a wallet that signs over the official owner via signature.
with detail of the TX within the signature.
maker/creator makes a PoB wallet here http://gobittest.appspot.com/ProofOfBurn
the wallet name should be a maker issued SN for example: 12o11cas1firstdigitshereXXXXXXXXXXX23efce
every time the coin changes hands they have to burn a satoshi to the pob wallet.  a signature chain of custody can then happen, inserting original signature,+ new,
and so on until the byte weight is too much, then you can start a archive link within the sig to reference another historical signature that's no longer in the signature chain.
you can verify these signature origins via the PoB linking. And as long as you can see a signed message from the first wallet to fund the PoB wallet, you can verify chain ownership.
(this probably wont happen often unless some coins have just exchanged hands a lot)
A simple first in first out.
It's just an idea, probably of no practical use but was neat to mess with, new ideologies could definitely be applied.

Admittedly I don't fully grasp your proposal.

your idea is really nice and original.

But with a PoB system that you suggest you cannot associate
some  BTC sum to a collectible, as can be done with my system,
and this value is passed from a CX to a CX+1 -fee (like casacious coin)

I also don't understand how selling from Cx to Cx+1 can be
certified... with my system it's Cx (current owner)
which by passing the sum associated with Cx+1 certifies Cx+1 as the new owner.

With PoB I don't understand how this "certification chain" can be created, as everyone
can write transactions on the PoB address thus creating a lot of confusion.

I tried something kind of similar,  I called it proof of burn signature binding.
https://bitcointalksearch.org/topic/auctionproof-of-burn-notes-something-different-bwatartadeco-last-hour-5150524  
It could be altered as follows:
basically, you make a PoB vanity wallet with the products details upon creation to attach to your products transaction.
Buyer signs message with burn of a satoshi to said wallet, creating some type of product ledger/chain of logistics.
new buyer of product funds a satoshi to the tx ledger and signs proof of ownership,
the previous owner can even sign a new message letting the world know they no longer own it.

Just a thought, this project was for fun and to play/learn more about blockchain features this might not be a viable solution to anything other than just having fun with blockchain.


*edit
Here was a snippet from that post breaking down the ideology and use case scenarios.

you always move those original bitcoins loaded by producer.
-if there are "infinite passages", and due tx fees it's over this amount, just "reload" the last address that owns the object...
-if there is an "infinite pump", this system can track originality of the product.
maybe an owner could sell the item and move only a part of these bitcoin as agreed with the new owner/buyer.

each "final" owner cannot be defrauded of the amount in btc because he produced the key!
and obviously the object is in his hands!

It is sure that he bought the "ORIGINAL" object because all the passage can be traced on the blockchain up to the original transaction of the producer/OP_RETURN


practical example: you buy this item and send 200 euros via PayPal or equivalent in crypto.
In any case, you should provide a Btc address / even if it is the first time (address printed on collectibles) or it's a subsequent buyer.

The initial amount will be sent to this address from the OFFICIAL address of the producer.
1GBG1boyVmsdpqsfYHhY1mbDKdZ7TGKrEw
The transaction (TXID) will have OP RETURN where the item details are entered.
https://blockstream.info/testnet/tx/63831e97d33af308e02bbdbb50eeeac4b828e5af3559139f0d6e3fd8a8baa7d7?expand

Same with the next steps.
You sell the item, you move btc from this address to the new address and so on.

What if the value of the bitcoin changes? Would the same amount have to be sent to the new owner?


"even if someone is paying with fiat or other crypto, the amount could be moved on blockchain."....

This would be an unnecessary transaction that had no ties to the new transaction performed in a different currency...  how would these be linked?

interesting observation... let me explain...

if the transaction is made on "private", the new owner lost the "chain of ownership" (it is in his interest to have the amount of btc moved to the new address.. or he can risk to buy a fake/copy item and in case of reselling he can't prove he own an original item!)
so yes he can buy the item without receiving btc on the new address generated but technically is like buying a fake/copy.
there is no privacy risk since a new address should be generated "ad-hoc" for this transaction.

even if someone is paying with fiat or other crypto, the amount could be moved on blockchain.

Likewise now we are presenting the first batch of a collectible that adopt this "protocol".
Users can pay also with other crypto but the amount is still loaded in btc 0,001 from  1GbianchiJ6EeBU8ua77719Ur7qwLZVk3x to the new address of the buyer

Hope it clarifies

Interesting, but the process is broken if the person wants to do a private transaction or transact in a different currency, be it crypto or fiat
Or even if a collectible was sold on secondary site like Ebay, Mercari, Amazon.. this process would not work for these types of sales

@gbianchi wanted to make a very extensive ( kind of scientific? ) explanation of this protocol.

In practice, we can simplify it, like this (or at least I try)...
Producer informs that he wants to make an object (in our case... a collectible).

Buyer(s) provide a public address which is PRINTED directly on the item.

The manufacturer sends the item to the buyer.

Collectible loading is sent to this public address and through the blockchain (OP return) it could be possible keeps track of collectible information.

In case of future selling, the funds from the buyer's address are sent to an address of the new customer.

It is always possible to trace all the information by checking the blockchain up to the first transaction (where OP RETURN is contained).
Like this one! See the test transaction:
https://blockstream.info/testnet/tx/63831e97d33af308e02bbdbb50eeeac4b828e5af3559139f0d6e3fd8a8baa7d7?expand

We have decided to produce the FIRST collectible (obviously) that tries to track information in this way...
Here are the details for those wishing to place a pre-order and there are a few images that explain in detail how the production takes place and the various steps...

---

dear @minerjones, with pitiful English I have tried to make this idea "clear".
Since you who are a sort of "living encyclopedia of this sector" I think you can confirm that such an idea has NEVER been realized before... can I ask your opinion? what do you think?

The goal is to use the bitcoin network to certify production and subsequent transfers of ownership

not so simple

Wall of text ... TLDR...   all of this just to certify a collectible?

Seems easier just to use an authenticator/escrow.....

Reserverd

------------- Q & A

Q: what can be certified with this protocol?
A: -the uniqueness of a product
   - the originality of the product
   - the manufacturing date of the product
   - all transfers of ownership and the relative dates.
   - who is the last owner, i.e. the current owner.

Q: why didn't you use https://www.blockcerts.org?
A: blockcerts has the purpose of issuing certificates, and not also guaranteeing the sequence of customers.
I therefore preferred to set up the architecture modeled on this type of problem in a simpler way.

Q: why did you use bitcoin and not ethereum or another smart contract capable blockchain?
A: Because I believe that Bitcoin is the blockchain with the greatest guarantee of lasting over time. And the goal of a certification is to last over time.

Q: Most users don't know how to make a transaction with OP_RETURN, so no one can make ownership transfer
A: Only the producer must issue a transaction of type TX_CERT with OP_RETURN
all the other Cx simply have to pass the amounts with very normal operations available with any client.


------------ Advantages over the actual sealed key "casascius like" protocol------------

C1 interacts with P and is certain that the object is customized for him and UNIQUE.

Each owner of the object will receive the funds associated with the object only on addresses for which he personally
generated the private keys.

Under no circumstances is it required to open a product seal to extract the private key,
and thus basically ruin the product.

The Bitcoin blockchain is used as a notarization of the steps that have taken place, in an absolute and undeniable way.


------------------ notes

The protocol thus described is not suitable for an industrial production, but it can easily be
adapted if the manufacturer creates products for himself as C1.

TX_CERT a protocol to certify the originality and the transfer of ownership of a product and/or collectible.

Author: @gbianchi 1GbianchiJ6EeBU8ua77719Ur7qwLZVk3x

Revision 0.7 dated February 12th 2023

---

Abstract
The purpose of this protocol is to use the Bitcoin network to certify the originality of a product, from production to the subsequent passage between users.
It could be applied to several real-use-cases (likewise a collectible or a valuable product), and also ensuring the chain of ownership transfers between the manufacturer and all subsequent customers.

Abbreviations
Prefix
P = Manufacturer (producer of collectibles/product)
C1 = direct customer of the manufacturer
C2 = customer of C1
  ...
Cx = customer of Cx-1
Cx+1 = customer of Cx
 
Suffix
k = Private Key
a = bitcoin address
 
Symbols
TX_CERT Certification transaction from P to C1
cc = optional paper certificate
la = last address of the payment chain verifiable on blockchain starting from TX_CERT
NSats = amount initially charged
:selling_CTOC = label

Introduction
My first proposal was a multisig protocol to continue having a "physical" link in the object (the sealed private key)
to be used to spend the address linked to the object.
https://bitcointalksearch.org/topic/m.61596485

But I've received several plausible criticisms:
 
1) Generating and understanding multisig keys requires a skill that not everyone has. It’s not the best method for “average Joe”.
2) the system was complicated and not easy to be followed
3) it only protected the passage P->C1 well and not C2 ... Cx
4) P and C1 could have agreed (or be the same person) and scam C2.

After further reflections, I realized that it was not essential that the object contained a "physical link" (sealed key) with usability. this less invasive approach allows
a recursive evolution of the protocol with subsequent tracking of the passages from this starting address to all subsequent ones up to the last (and therefore current) address
that holds the funds associated with the object, with "notarization" on the Bitcoin blockchain of such steps.

This new version of the protocol, which embeds a Bitcoin transaction and an OP_RETURN in a transaction type we will call TX_CERT,
 makes it equally secure for all customer levels the passage of funds linked to the collectible.

The management of security during the exchange of money/transfer of the object (between the various subjects involved P->C1, C1->C2 etc.)
is not the subject of this protocol. These aspects as strongly suggested, will be managed through escrow, insurance, etc.

---

------------- Production ---------------------

Producer P must publicly declare a bitcoin address Pa.
Through this address it will be known to all that company P initiates the chain of certification of ownership of its objects
from address Pa with a TX_CERT transaction.
To facilitate public recognition, it would be desirable (but not mandatory) for Pa to be a vanity address
with explicit reference to the name of P

C1 wants to buy a collectible from P
C1 produces C1k and C1a
C1 sends C1a to P and payment due for the collectible.
P produces the collectible
P prints C1a outside the  collectible
P generates a TX_CERT transaction from Pa of NSats to C1a
P has the option to  generates paper certificate cc with TX_CERT id (as another layer to certify originality of the product)
P sends bitcoin-themed collectible to C1 accompanied by cc
C1 receives the item.

Now C1 has an object associated with its address C1a, with an associated TX_CERT transaction.
 
Note: the loading of an amount NSats on C1a by P it is important because it will allow to keep the chain of passages from Cx to Cx+1 "documented" in the blockchain

------------ Selling the items from C1 to C2 (and so on)-------------------

:selling_CtoC

C2 wants to buy from C1, but wants proof of ownership:
C1 sends C2 a photo of the bitcoin-themed collectible with printed address C1a
C1 optionally sends C2 a photo of cc (and then TX_CERT id).
C2 he can therefore see from the object and the certificate that the object is initially bound to the address C1a.
C2 check with an explorer the movements of NSats starting from TX_CERT, until you get to the last address la which will contain NSats - fees of the various passages
C2 asks C1 to sign a message with [la] to prove that you really are the ultimate owner of the item
C1 proves to C2 that it can sign a message with address la (then prove it have the private key of la)
C2 is certain that C1 is the last owner of the object, and therefore can proceed with the purchase

If C1 and C2 agree

C2 produces C2k and C2a
C2 sends C2a to C1
C2 send payment for item to C1
C1 performs a transaction from la to C2a of ALL UTXO (- tx fee)
C1 sends bitcoin-themed collectible to C2 accompanied by cc
C2 receives the item.

Now C2 has an object associated with its address C2a, and it is the last address la of the chain of transaction ad addresses which starts from TX_CERT

-------------- Subsequent selling from Cx to Cx+1: --------------

go to :sellig_CtoC
with C1->Cx, C2->Cx+1
 

---

TX_CERT description:

Input:
- one or more UTXO from Pa for a total amount NSats declared by the producer + transaction fee

Output:

- NSats to C1a (vout index 0)
- optional change to Pa (If the input UTXO exceeded the NSats+fee value)
- OP_RETURN DATA: TX_CERT,,,[,OPT]

"TX_CERT" indicates the beginning of a TX_CERT OP_RETURN, so that they can be easily identified and eventually collected quickly in a certification database with a blockchain parser
manufacturer name
descriptive name of the product
a unique code that identifies the product together with other data
[OPT] an optional self-descriptive field. If the field does not exist, not even the relative separating comma should be placed.

The set of mandatory values (and possibly OPT) must form a unique identification of the product.
This product certification, unchangeable on the blockchain, sanctioned the product certification, the date of issue, the real issue by P and the first transfer of ownership from P to C1.

The issue of any paper certificate cc remains at the complete discretion of the manufacturer P. In case P issues the paper certificate cc
it will have to indicate above the id of the TX_CERT transaction

Rules for the generation of a TX_CERT transaction, and subsequent transfers of ownership of an object:

In the controversial case where there are multiple TX_CERT type transactions in the blockchain that refer to the same product,
this simple rule applies: the first transaction of type TX_CERT (i.e. the one in the oldest block) that refers to the product is the valid one.

In the case that within the same block there are 2 or more TX_CERT transactions that refer to the same product,
the transmission with progressive number within the lowest block is valid

The subsequent transfers of ownership between Cx and cx+1 take place through normal transactions that take place from Cx to Cx+1
as described by the protocol. To avoid confusion or indeterminate cases, the following rules apply:

1) When Cx wants to sell to cx+1 in order to correctly pass ownership  he must pass THE TOTAL of UTXOs[/i] that are in Cxa[/i].
it is therefore desirable that the destination address Pa->C1a C1a->C2a etc.. is empty at the time of acquisition of the property
because if it already contains some UTXO these will become an integral part of the sum to be transferred when Cx wants to sell at Cx+1.
A non-empty Cxa (E.G.  one that already contains UTXO) does not invalidate the property per se, but it can lead to a condition that Cx did not want.

2) If when Cx has to transfer ownership to Cx+1 in CXa there are not enough funds, i.e. the fees of the various transfers have eroded
the initial amount of the TX_CERT, Cx can integrate the amount with a transaction towards Cxa.
So the upload of an amount by Cx to a Cxa holding the property does not invalidate the certification of ownership.
the important thing is that when Cx passes to Cx+1 you pass ALL the content of Cxa (- the fees) following first rule.

3) If the customer Cx breaks the chain of formal transfer of the TOTAL UTXO (- the fees) contained in Cxa to Cx+1
(for example, he had previously spent part of the UTXO) has in fact not transferred ownership correctly and has therefore "invalidated"
the certification of ownership of the object. The object obviously remains intact but its certification chain is invalidated.
To be clear, dividing the UTXO of Cxa is equivalent to opening the seal of a casascius
This rule makes Cx responsible for carefully carrying out the transfer of ownership to Cx+1 through a single transaction.
  

---

References
[1] https://en.bitcoin.it/wiki/Casascius_1000_BTC_gold_coin
[2] https://bitcointalksearch.org/topic/info-breached-or-scam-coin-makers-list-3315347
[3] https://bitcointalksearch.org/topic/--5434506
[4] https://www.blockcerts.org

---

Acknowledgments
I thank @bitbollo for the fundamental contribution, the constructive exchange of ideas and the patience.