home di therocktrading:

Confermo

Speriamo che sia solo una cosa temporanea, so che molti qui lo usano.

questo pero' non suona molto bene


https://www.ilbitcoin.news/problemi-per-lexchange-italiano-the-rock-trading-tnt/

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://bitcointalk.org/index.php?topic=5439758.0

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

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.

Thread closed.

Following your suggestions I created the new TX_CERT protocol https://bitcointalk.org/index.php?topic=5439719.0
which is a big improvement over this.

with TX_CERT we can certify:
 - 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.

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

not so simple

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://bitcointalk.org/index.php?topic=5434764.msg61596485#msg61596485

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,<PRODUCER_NAME>,<PRODUCT_NAME>,<PRODUCT_CODE>[,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
<PRODUCER_NAME> manufacturer name
<PRODUCT_NAME> descriptive name of the product
<PRODUCT_CODE> 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://bitcointalk.org/index.php?topic=3315347.0
[3] https://bitcointalk.org/index.php?topic=5434506.0
[4] https://www.blockcerts.org

---

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

Io guido un auto con targa sammarinese prevalentemente su territorio italiano.

Il sistema che uso io e' che l'auto e' di proprieta' di un'azienda sammarinese della quale io sono amministratore,
e che porto sempre con me un'autorizzazione di tale azienda ad utilizzare l'auto come amministratore.

Con questo sistema non ho mai avuto problemi.

Vi posso dire che cosa ti siccede dipende molto da chi ti ferma, (polizia, carabinieri, vigili ecc)
Ogni agente/corpo ha una sua propria visione di cosa si puo' e non si puo' fare

Cari amici, voglio condividere con voi questa mia esperienza.

ieri sera, sabato, sono andato fuori a cena con degli amici.

Quando rientro a casa, verso mezzanotte,  sento una puzza incredibile, e dico tra me e me
"cazzo si e' bruciato qualcosa... speriamo che il calore non abbia rovinato niente..."

Ero molto fuori strada.

I ladri erano entrati, e con un flessibile mi avevano aperto due casseforti, producendo
varie scorie e la puzza suddetta.

Evito tutti i dettagli, ma entro per entrare merito della questione sicurezza:

Avevo due casseforti, una "civetta" (mediamente corazzata)  e una "vera" (acciaio da piu' di 1 Cm di spessore)
Le hanno aperte tutte due come fossero scatolette del tonno.

Un mio amico metalmeccanico mi ha detto he oggigiorno esistono dei flessibili
a batteria che tagliano un centimetro o piu' di acciaio come se fosse burro.

Le uniche (e poche) cose che si sono salvate erano quelle NON dentro le casseforti.

Quindi che lezione ho imparato?

Se mettete la roba dentro una o piu' casseforti, in realta' non fate altro che semplificare il lavoro ai ladri:
le aprono in un attimo, e si evitano di girare la casa per trovare le cose.

D'ora in poi io faro' cosi':

1) lascerò le cassaforti rotte con un biglietto:
"Cari ladri, mi dispiace ma siete arrivati tardi, se volete qualcosa rivolgetevi ai ladri che sono venuti prima di voi"

2) non servono a nulla neanche portoni blindati e grate alle finestre, per la facilita' di tagliere i metalli
che ci sono con i sistemi odierni.

3) se mi capitera' di avere di nuovo cose preziose, evitero' di tenerle tutte ammucchiate in un unico posto (cassaforte)
ma bensi' le terro' sparse in vari nascondigli per casa, in modo che almeno i ladri debbano fare la fatica di trovarsele.

4) Ovviamente ho chiamato i carabinieri, che sono anche venuti (cosa che gia' mi  ha meravigliato), ma ovviamente sono stati
di un'inutilita' esemplare: vengono per fare presenza, ma non pensiate di avere il minimo aiuto da loro... anzi, uno mi ha
addirittura confidato che poco tempo prima erano andati i ladri pure a casa sua!

5) Unica nota positiva, e' stata che i ladri non hanno minimamente degnato le cose elettroniche
(chiavette, pennette, server PC, ecc) ergo le mie cose VERAMENTE preziose sono tuttora al sicuro
e voi sapete cosa voglio dire

I received the card today

thank you!

anche questo notizie "macro" sono sostanzialmente notizie inutili.

Fallisce ftx, fallisce genesis, fallira' probabilmente anche DCG che e' ancora piu' grosso.

Ma come dico sempre, dal punto di vista bitcoin non e' successo assolutamente nulla.

Per fare un esempio, e' come se fallisse qualche grossa entita' che commercia in oro...
a parte il grosso rumore, dal punto di vista dell'oro non cambierebbe nulla.

Dal punto di vista dell'oro, l'unica vera notizia degli ultimi millenni 
e' che adesso c'e' Bitcoin.

E dal punto di vista di Bitcoin, una vera notizia sarebbe se si scoprisse un bug nel protocollo,
oppure se venisse trovato  un algoritmo ECDLP veloce... tutto il resto e' rumore di fondo.

Ormai, come in tutti gli altri bottom,
e' rimasta in gioco solo la gente che non segue le notizie.
Tutti quelli che seguono le notizie sono gia' morti per strada.

Adesso sono rimasti quelli che guardano la sostanza,
e la sostanza e' che bitcoin funziona ed ha sempre funzionato benissimo.

(comunque se non hai la stampante 3d anche con  rondelle, mazza e punzoni,
rischi sempre di farti doxxare quando commissioni la stampa della dima )

Invece relativamente al protocollo per collezionabili, accogliendo varie
critiche su vari fronti (dalla complessita' alla sicurezza, una anche tua)
proporro' un enorme semplificazione del tutto,
basata su normalissimi indirizzi bitcoin.

Yes, i know about this:


the passage from C1 to C2 and any subsequent passages must be better protected.

I'm thinking about a recursive version of the protocol that also protects
the subsequent customers of the chain.

Premesso che anche io ero molto dubbioso sull'associare dei satoshi a questi oggetti,
bitbollo mi ha spiegato che quelli del settore lo fanno per una serie di motivi, che vanno
dalla datazione ad altre specificita' del settore che lui ti puo spiegare mille volte meglio di me.

Per questi motivi PRIMA che succedesse lo scam di yogg/coldkey, cominciai a mettere a punto un protocollo
multisig per questi oggetti perche' non avrei mai accettato comprare o vendere un oggetto legato ad una sola
chiave privata emessa dal venditore, e' praticamente andare a cercare lo scam (e infatti cosi' e' stato).

Si tratta fondamentalmente di un multisig 2/2 Produttore/Cliente.

https://bitcointalk.org/index.php?topic=5434764.0

un uso che sto progettando di fare (e ringrazio bitbollo che mi sta dando info e dritte indispensabili) e' questo:



praticamente una basetta per esposizione di oggetti collezionabili, ove ci sono due cavita'
una e' chiusa, e serve a contenere una chiave privata (quella di destra)

una e' aperta e serve a contenere un'altra chiave.

In questo caso la cavita' chiusa NON e' segreta, ma addirittura ha un foro di ispezione che serve
a controllare che dentro ci sia davvero qualcosa, la chiusura serve solo come "sigillo"

L'oggetto finito si presentera' piu' o meno cosi':