Comments (6)
Comment by Alekos:
Pay to contract is not a consensus mechanism, it's just a way to put stuff on the blockchain. In the case of multisig I don't think you would need to tweak all of them (just the first one is fine), but you would also need to reveal the entire scriptPubKey in the proof, so that on the other end it can be checked
from spec.
Well, in case of asymmetric multisigs, like 1-of-3, we need to ensure that any of the participants canโt spend UTXO without proper care of RGB assets, and this will require all three public keys to be tweaked
True, we need it as a field within the proof
from spec.
you would also need to reveal the entire scriptPubKey in the proof, so that on the other end it can be checked
A multisig wallet is able to generate its scriptPubKeys yet. After the assets are moved scriptPubKeys are stored into the blockchain and everyone could see them. So I think it is not needed to include scripts inside proofs.
from spec.
Well, in case of asymmetric multisigs, like 1-of-3, we need to ensure that any of the participants canโt spend UTXO without proper care of RGB assets, and this will require all three public keys to be tweaked
I think that there is no need to tweak pubkeys in order to avoid errors like these. It is simpler to use a different BIP 43 purpose code for RGB aware wallets. Moreover, the RGB awareness should be encoded also into extended pubkeys
from spec.
I think we need to leave the question to the market and let it define the best practice. This means that users should be given an option to choose (either via wallet configuration - or by using some wallets with embedded security policies) whether they tweak all public keys as a matter of funds security - or just some of them. The protocol should not force some particular behaviour and be flexible and simple as much as possible. In this case it seems that the fee-defined vout looks like the best option, and if the tweaked key is kept in a multisig-wallet address, all keys should be tweaked. Otherwise, those who prefer simplicity may tweak only one public key in some of change outputs.
from spec.
Due to the recent updates in #93 and #92 it seems that we have no other option for v1 other than to skip any commitments inside multisigs โ and any P2(W)SH and commit to the other output.
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.