Comments (9)
@afilini can you pls elaborate on this issue you've proposed in the roadmap?
from spec.
Seems like the actual discussion are happening underneath PR #59. Copying the last proposal from there:
With the current RGB spec we can already spend assets to an existing UTXOs and have a separate flow of the assets independent from the flow of the bitcoins. This will not work for Spectrum, but completely fine for the on-chain transfers.
In order to obsucate UTXOs until the proofs are spent, we can use HMAC, as proposed in the mentioned PR #59 – but with a key for HMAC being the actual public key, corresponding to the UTXO address. This key is not known before the actual UTXO is spend — and when it is being spent, it becomes public, so no reason to add it to the proof, meaning there would be no size increase for the proof.
from spec.
The actual RGB spec has to be improved in pay-to-existing UTXO part in a way that we need to have two states of the proof: an initial, with only HMAC_SHA256(utxo_public_key, txid:vout) serialized – which should be included into the proof commitment – with this data being replaced later, when the UTXO is spend, with the actual txid and vout in a non-hashed form. This will not break the commitment, since a verifying party would be able to compute HMAC the proof was committed to from these data + public key in the spent tx output (related issue: #98 )
from spec.
This key is not known before the actual UTXO is spend — and when it is being spent, it becomes public
It shoudn't become public after the UTXO is spent. The idea is that you require the the next proof to know the UTXO, so the sender will never know it
from spec.
@inaltoasinistra, ok, let me re-phrase it in a correct way.
The proof is passes several stages.
- "Unspent proof": the proof is created by the payer (Alice). It receives from the payee (Bob) the hash, which is
HMAC_SHA256(public_key, txid || vout)
and includes it into the proof, committing to it with either P2C or OP_RETURN commitments. This proof is passed then to Bob and kept in this stage. Nobody else except Bob know where the bound asset, owned by Bob, resides. - "Spent proof": when Bob needs to spend (part of) the asset to Carol, he changes the proof structure in the following way:
- removes original HMAC_SHA256 and replaces it with explicit txid:vout information
- spends the UTXO to which the proof was bound, making
public_key
explicitly available in bitcoin blockchain to everybody who knows the original UTXO (at this point nobody except Bob himself
After this operation Bob transfers updated proof + a newly created proof to Carol. Now Carol also knows which output Bob has spent and had his assets bound to – but this is unavoidable anyway in order to verify the proof and prevent double spend. Original payee, Alice, still do not know which UTXO was used.
Will this work?
from spec.
Original payee, Alice, still do not know which UTXO was used.
Alice can discover which is the UTXO computing the hash on all the outputs of the blockchain with the same rule. When she finds the correct hash she knows the UTXO.
This operation is cheap, a bitcoin node uses more resources
from spec.
True, but not when the payee (Bob) uses a new public hash (HD-derived, for instance). And since it is in his interest to preserve the privacy, he will do that.
from spec.
Also new public keys are exposed when UTXOs are spent. So Alice could check all the public keys of new blocks until she found the correct key
from spec.
After the team meeting at @inbitcoin it was decided to abandon this change, since
a) it does provide very limited temporally privacy trading on a lot of complexity
b) if the privacy is the concern, its better to adapt some best practices from zero-knowledge proofs, like in confidential assets.
from spec.
Related Issues (20)
- Proofs must be commited only to the TX spending colored UTXO, not the arbitrary one
- Possible double-spend with double-commitment HOT 12
- Improve spec on contract deployment HOT 2
- Depreciate OP_RETURN commitments for contract deployments
- Improve single use seals mechanism for contract reissuing HOT 1
- Preserve some space in proofs by using RIPMD160 hashes HOT 1
- Can commitment_txid be pruned in UTXO-based transfers? HOT 6
- Inflation txout naming HOT 1
- Version upgrade proofs must spend only inputs with the same version number
- Add reference and link to LNPBP repo? HOT 3
- https://rgb.network is down / not resolving HOT 4
- Why we use addition instead of multiplication in public key tweaking HOT 10
- Nested proof structure results in very large proofs for transfers with multiple inputs HOT 4
- How to deterministically define output containing the tweaked key for P2C schemes HOT 12
- Increasing asset safety by combining commitment output with asset binding output HOT 6
- No support for spending single RGB output from the proof HOT 2
- Proposed Spectrum tx structure HOT 3
- Add versioning to RGB protocol
- Update proof structure separating commitment and prunable parts
- Do we need to verify that P2C commitment tx is not older than asset-binding tx? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from spec.