Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun wrote: > Hi Bram, > > > The witnesses for transactions need to be put into Bitcoin transactions > > even though the Bitcoin layer doesn't understand them > > Is this related to Ruben's comment about invalid state transitions > (published in the base chain) leading to burned assets? > Yes, or at least the concern that a valid transaction could have its required witness data not posted to the chain and be effectively bricked. > In the past, I've > considered using the existing annex field in taproot transactions to > implement partial reveal of certain data. However, today bitcoind treats > annex usage as non-standard, so those transactions may be harder to relay. > IMO this is a great place to add minimal extra data, as it doesn't bleed > over into > the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures > also include this field in the sighash, the sigs serve to further > authenticate this data. > That leads to a bit of a philosophical question: Is the annex reserved for possible future Bitcoin script soft forks, or is it free to use for whatever with confidence there won't be a future collision? But that might not matter, because if the purpose is to force the extra witness information to be published it has to be in something signed in the transaction, and barring a check sig from stack that probably means it has to be shoved into the transaction somewhere. > > Taro issuance is limited to a single event rather than potentially > > multiple events over time subject to special per-asset rules. > > There's a provision in the protocol that lets a party issuing assets to > specify a special public key which is then tweaked with the genesis > outpoint, similar to the way the asset IDs are generated. If this key is > specified, then future issuance, if signed off by that key, will serve to > associate assets of discrete IDs under a single identifier. This feature > allows assets issued in multiple tranches to be fungible with one another. > Ah I see. That's still a fairly bespoke set of functionality instead of allowing an arbitrary script to be used for the issuance (but that again runs into Bitcoin script being fairly limited in its functionality). > > > but I am puzzled by the announcement saying Taro assets are 'analogous > > with' colored coins. Taro assets are straightforwardly and unambiguously > > colored coins and that isn't something to be ashamed of. > > We've shied away from using the "colored coins' terminology as at this > point > in the game it's pretty dated: new developers that joined in the last 3 > years or so have likely never heard of that term. Explaining the term also > requires one to define "coin coloring", and what that actually means, etc, > etc. IMO it's simpler to just use the familiar and widely used asset > issuance/minting terminology. > People mostly haven't heard of colored coins in a while because everything has been based on ERC-20 style tokens, which are truly horrid. Coloring is a meaningful technical term which means something good, although unfortunately the term 'colored' is a bit loaded in different ways around the world so it's best to keep it in the technical docs. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Hi Ruben, > Also, the people that are responsible for the current shape of RGB aren't > the people who originated the idea, so it would not be fair to the > originators either (Peter Todd, Alekos Filini, Giacomo Zucco). Sure I have no problems acknowledging them in the current BIP draft. Both the protocols build off of ideas re client-side-validation, but then end up exploring different parts of the large design space. Peter Todd is already there, but I can add the others you've listed. I might even just expand that section into a longer "Related Work" section along the way. > What I tried to say was that it does not make sense to build scripting > support into Taro, because you can't actually do anything interesting with > it due to this limitation. can do with their own Taro tokens, or else he > will burn them – not very useful I agree that the usage will be somewhat context specific, and dependent on the security properties one is after. In the current purposefully simplified version, it's correct that ignoring the rules leads to assets being burnt, but in most cases imo that's a sufficient enough incentive to maintain and validate the relevant set of witnesses. I was thinking about the scripting layer a bit over the weekend, and came up with a "issuance covenant" design sketch that may or may not be useful. At a high level, lets say we extend the system to allow a specified (so a new asset type) or generalized script to be validated when an asset issuance transaction is being validated. If we add some new domain specific covenant op codes at the Taro level, then we'd be able to validate issuance events like: * "Issuing N units of this assets can only be done if 1.5*N units of BTC are present in the nth output of the minting transaction. In addition, the output created must commit to a NUMs point for the internal key, meaning that only a script path is possible. The script paths must be revealed, with the only acceptable unlocking leaf being a time lock of 9 months". I don't fully have a concrete protocol that would use something like that, but that was an attempt to express certain collateralization requirements for issuing certain assets. Verifiers would only recognize that asset if the issuance covenant script passes, and (perhaps) the absolute timelock on those coins hasn't expired yet. This seems like a useful primitive for creating assets that are somehow backed by on-chain BTC collateralization. However this is just a design sketch that needs to answer questions like: * are the assets still valid after that timeout period, or are they considered to be burnt? * assuming that the "asset key family" (used to authorize issuance of related assets) are jointly owned, and maintained in a canonical Universe, then would it be possible for 3rd parties to verify the level of collateralization on-chain, with the join parties maintaining the pool of collateralized assets accordingly? * continuing with the above, is it feasible to use a DLC script within one of these fixed tapscript leaves to allow more collateral to be added/removed from the pool backing those assets? I think it's too early to conclude that the scripting layer isn't useful. Over time I plan to add more concrete ideas like the above to the section tracking the types of applications that can be built on Taro. > So theoretically you could get Bitcoin covenants to enforce certain > spending conditions on Taro assets. Not sure how practical that ends up > being, but intriguing to consider. Exactly! Exactly how practical it ends up being would depend on the types of covenants deployed in the future. With something like a TLUV and OP_CAT (as they're sufficiently generalized vs adding op codes to very the proofs) a Script would be able to re-create the set of commitments to restrict the set of outputs that can be created after spending. One would use OP_CAT to handle re-creating the taro asset root, and TLUV (or something similar) to handle the Bitcoin tapscript part (swap out leaf index 0 where the taro commitment is, etc). > The above also reminds me of another potential issue which you need to be > aware of, if you're not already. Similar to my comment about how the > location of the Taro tree inside the taproot tree needs to be > deterministic for the verifier, the output in which you place the Taro > tree also needs to be Yep, the location needs to be fully specified which includes factoring the output index as well. A simple way to restrict this would just to say it's always the first output. Otherwise, you could lift the output index into the asset ID calculation. -- Laolu ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Simple step one for quantum
FWICT: Streamlined NTRU Prime (sntrup) has no known patent issues. Should be fine. Regardless, a "double-wrapped bitcoin address of some kind" can be specified, coded up and the relevant module replaced whenever the dust settles. I know Bitcoin doesn't (yet) have fee "weights", but i still think these addresses should be called "heavier" if they are at al significantly slower to validate. On Mon, Apr 11, 2022 at 2:07 PM Olaoluwa Osuntokun wrote: > The NIST Post-Quantum Cryptography competition [1] results should be > published "soon": > > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ > . > > The last reply on that thread promised results by the end of March, but > since that has come and gone, I think it's safe to expect results by the > end > of this month (April). FWIW, NTRU and NTRU Prime both made it to round 3 > for > the public key encryption/exchange and digital signature categories, but > both of them seem to be mired in some sort of patent controversy atm... > > -- Laolu > > [1]: https://csrc.nist.gov/Projects/post-quantum-cryptography > > On Fri, Apr 8, 2022 at 5:36 PM Erik Aronesty via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> First step could be just implementing a similar address type >> (secp26k1+NTRU) and associated validation as a soft fork >> >> https://www.openssh.com/releasenotes.html#9.0 >> >> Then people can opt-in to quantum safe addresses >> >> Still should work with schnorr and other things >> >> It's a lot of work to fold this in and it's a some extra validation work >> for nodes >> >> Adding a fee premium for using these addresses in order to address that >> concern seems reasonable >> >> I'm not saying I endorse any action at all. Personally I think this is >> putting the cart like six and a half miles in front of the horse. >> >> But if there's a lot of people that are like yeah please do this, I'd be >> happy to make an NTRU bip or something. >> >> >> >> >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay
Hi Bram, > The witnesses for transactions need to be put into Bitcoin transactions > even though the Bitcoin layer doesn't understand them Is this related to Ruben's comment about invalid state transitions (published in the base chain) leading to burned assets? In the past, I've considered using the existing annex field in taproot transactions to implement partial reveal of certain data. However, today bitcoind treats annex usage as non-standard, so those transactions may be harder to relay. IMO this is a great place to add minimal extra data, as it doesn't bleed over into the scripting layer (via OP_DROP usages) and since Bitcoin-level signatures also include this field in the sighash, the sigs serve to further authenticate this data. Future op codes that allow Scripts to push annex data onto the stack could also be used to further bind higher level protocols while still allowing the base Bitcoin consensus rules to not have to be explicitly aware of them. > Taro issuance is limited to a single event rather than potentially > multiple events over time subject to special per-asset rules. There's a provision in the protocol that lets a party issuing assets to specify a special public key which is then tweaked with the genesis outpoint, similar to the way the asset IDs are generated. If this key is specified, then future issuance, if signed off by that key, will serve to associate assets of discrete IDs under a single identifier. This feature allows assets issued in multiple tranches to be fungible with one another. > but I am puzzled by the announcement saying Taro assets are 'analogous > with' colored coins. Taro assets are straightforwardly and unambiguously > colored coins and that isn't something to be ashamed of. We've shied away from using the "colored coins' terminology as at this point in the game it's pretty dated: new developers that joined in the last 3 years or so have likely never heard of that term. Explaining the term also requires one to define "coin coloring", and what that actually means, etc, etc. IMO it's simpler to just use the familiar and widely used asset issuance/minting terminology. -- Laolu On Sun, Apr 10, 2022 at 9:10 PM Bram Cohen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > From: Olaoluwa Osuntokun > >> >> > Furthermore, the Taro script is not enforced by Bitcoin, meaning those >> who >> > control the Bitcoin script can always choose to ignore the Taro script >> and >> > destroy the Taro assets as a result. >> >> This is correct, as a result in most contexts, an incentive exists for the >> holder of an asset to observe the Taro validation rules as otherwise, >> their >> assets are burnt in the process from the PoV of asset verifiers. In the >> single >> party case things are pretty straight forward, but more care needs to be >> taken >> in cases where one attempts to express partial application and permits >> anyone >> to spend a UTXO in question. >> >> By strongly binding all assets to Bitcoin UTXOs, we resolve issues related >> to >> double spending or duplicate assets, but needs to mind the fact that >> assets >> can >> be burnt if a user doesn't supply a valid witness. There're likely ways to >> get >> around this by lessening the binding to Bitcoin UTXO's, but then the >> system >> would need to be able to collect, retain and order all the set of possible >> spends, essentially requiring a parallel network. The core of the system >> as >> it >> stands today is pretty simple (which was an explicit design goal to avoid >> getting forever distracted by the large design space), with a minimal >> implementation being relatively compact given all the Bitcoin >> context/design >> re-use. >> > > The TARO set of tradeoffs is fairly coherent but is subject to certain > limitations (modulo my understanding of it being off): > > The witnesses for transactions need to be put into Bitcoin transactions > even though the Bitcoin layer doesn't understand them > > There needs to be a constraint on Taro transactions which is understood by > the Bitcoin layer (which often/usually happens naturally because there's a > user signature but sometimes doesn't. It's a limitation) > > Multiple Taro coins can't consolidate their value into a single output > because they only support a single linear history > > Taro issuance is limited to a single event rather than potentially > multiple events over time subject to special per-asset rules. > > This seems like a fairly logical approach (although my understanding of > the limitations/tradeoffs could be wrong, especially with regards to > consolidation). There's nothing wrong with a system having well documented > limitations, but I am puzzled by the announcement saying Taro assets are > 'analogous with' colored coins. Taro assets are straightforwardly and > unambiguously colored coins and that isn't something to be ashamed of. > ___ > bitcoin-dev mailing list >
Re: [bitcoin-dev] Simple step one for quantum
The NIST Post-Quantum Cryptography competition [1] results should be published "soon": https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/fvnhyQ25jUg/m/-pYN2nshBgAJ . The last reply on that thread promised results by the end of March, but since that has come and gone, I think it's safe to expect results by the end of this month (April). FWIW, NTRU and NTRU Prime both made it to round 3 for the public key encryption/exchange and digital signature categories, but both of them seem to be mired in some sort of patent controversy atm... -- Laolu [1]: https://csrc.nist.gov/Projects/post-quantum-cryptography On Fri, Apr 8, 2022 at 5:36 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > First step could be just implementing a similar address type > (secp26k1+NTRU) and associated validation as a soft fork > > https://www.openssh.com/releasenotes.html#9.0 > > Then people can opt-in to quantum safe addresses > > Still should work with schnorr and other things > > It's a lot of work to fold this in and it's a some extra validation work > for nodes > > Adding a fee premium for using these addresses in order to address that > concern seems reasonable > > I'm not saying I endorse any action at all. Personally I think this is > putting the cart like six and a half miles in front of the horse. > > But if there's a lot of people that are like yeah please do this, I'd be > happy to make an NTRU bip or something. > > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
> nonsense marketing I'm sure the people who are confused about "blockchain schemes as \"world computers\" and other nonsense marketing" are avid and regular readers of the bitcoin devs mailing list so I offer my sincerest apologies to all members of the intersection of those sets who were confused by the description given. > useless work progress is not useless work, it *is* useful work in this context. you have committed to some subset of data that you requested -- if it was 'useless', why did you *ever* bother to commit it in the first place? However, it is not 'maximally useful' in some sense. However, progress is progress -- suppose you only confirmed 50% of the commitments, is that not progress? If you just happened to observe 50% of the commitments commit because of proximity to the time a block was mined and tx propagation naturally would you call it useless? > Remember that OTS simply proves data in the past. Nothing more. > OTS doesn't have a chain of transactions Gotcha -- I've not been able to find an actual spec of Open Time Stamps anywhere, so I suppose I just assumed based on how I think it *should* work. Having a chain of transactions would serve to linearize history of OTS commitments which would let you prove, given reorgs, that knowledge of commit A was before B a bit more robustly. > I'd rather do one transaction with all pending commitments at a particular time rather than waste money on mining two transactions for a given set of commitments This sounds like a personal preference v.s. a technical requirement. You aren't doing any extra transactions in the model i showed, what you're doing is selecting the window for the next based on the prior conf. See the diagram below, you would have to (if OTS is correct) support this sort of 'attempt/confirm' head that tracks attempted commitments and confirmed ones and 'rewinds' after a confirm to make the next commit contain the prior attempts that didn't make it. [.] --^ confirm head tx 0 at height 34 ^ attempt head after tx 0 ---^ confirm head tx 1 at height 35 --^ attempt head after tx 1 ^ confirm head tx 2 at height 36 ---^ attempt head after tx 2 ---^ confirm head tx 3 at height 37 you can compare this to a "spherical cow" model where RBF is always perfect and guaranteed inclusion: [.] --^ confirm head tx 0 at height 34 -^ confirm head tx 1 at height 35 ---^ confirm head at tx 1 height 36 -^ confirm head tx 3 at height 37 The same number of transactions gets used over the time period. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote: > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote: > > > Let's discuss those too. Feel free to point out how bip8 fails at some > > > hypothetical cases speedy trial doesn't. > > Any case where a flawed proposal makes it through getting activation > > parameters set and released, but doesn't achieve supermajority hashpower > > support is made worse by bip8/lot=true in comparison to speedy trial > I disagree. Also, again, not the hypothetical case I want to discuss. You just said "Let's discuss those" and "Feel free to point out how bip8 fails at some hypothetical cases speedy trial doesn't", now you're saying it's not what you want to discuss? But the above does include your "evil soft fork" hypothetical (I mean, unless you think being evil isn't a flaw?). The evil soft fork gets proposed, and due to some failure in review, merged with activation parameters set (via either speedy trial or bip8), then: a) supermajority hashpower support is achieved quickly: - both speedy trial and bip8+lot=true activate the evil fork b) supermajority hashpower support is achieved slowly: - speedy trial does *not* activate the evil fork, as it times out quickly - bip8 *does* activate the fork c) supermajority hashpower support support is never achieved: - speedy trial does *not* activate the evil fork - bip8+lot=false does *not* activate the evil fork, but only after a long timeout - bip8+lot=true *does* activate the evil fork In case (a), they both do the same thing; in case (b) speedy trial is superior to bip8 no matter whether lot=true/false since it blocks the evil fork, and in case (c) speedy trial is better than lot=false because it's quicker, and much better than lot=true because lot=true activates the evil fork. > > > > 0') someone has come up with a good idea (yay!) > > > > 1') most of bitcoin is enthusiastically behind the idea > > > > 2') an enemy of bitcoin is essentially alone in trying to stop it > > > > 3') almost everyone remains enthusiastic, despite that guy's > > incoherent > > > > raving > > > > 4') nevertheless, the enemies of bitcoin should have the power to stop > > > > the good idea > > > "That guy's incoherent raving" > > > "I'm just disagreeing". > > > > Uh, you realise the above is an alternative hypothetical, and not talking > > about you? I would have thought "that guy" being "an enemy of bitcoin" > > made that obvious... I think you're mistaken; I don't think your emails > > are incoherent ravings. > Do you realize IT IS NOT the hypothetical case I wanted to discuss. Yes, that's what "alternative" means: a different one. > I'm sorry, but I'm tired of trying to explain. and quite, honestly, you > don't seem interested in listening to me and understanding me at all, but > only in "addressing my concerns". Obviously we understand different things > by "addressing concerns". > Perhaps it's the language barrier or something. My claim is that for *any* bad (evil, flawed, whatever) softfork, then attempting activation via bip8 is *never* superior to speedy trial, and in some cases is worse. If I'm missing something, you only need to work through a single example to demonstrate I'm wrong, which seems like it ought to be easy... But just saying "I disagree" and "I don't want to talk about that" isn't going to convince anyone. I really don't think the claim above should be surprising; bip8 is meant for activating good proposals, bad ones need to be stopped in review -- as "pushd" has said in this thread: "Flawed proposal making it through activation is a failure of review process", and Luke's said similar things as well. The point of bip8 isn't to make it easier to reject bad forks, it's to make it easier to ensure *good* forks don't get rejected. But that's not your hypothetical, and you don't want to talk about all the ways to stop an evil fork prior to an activation attempt... Cheers, aj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-core-dev] Bitcoin Core 23.0 release candidate 4 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Binaries for bitcoin Core version 23.0rc4 are available from: https://bitcoincore.org/bin/bitcoin-core-23.0/test.rc4/ The source code can be found in git under the signed tag https://github.com/bitcoin/bitcoin/tree/v23.0rc4 This is a release candidate for a new major version release. Preliminary release notes for the release can be found here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/23.0-Release-Notes-draft Release candidates are test versions for releases. If no critical problems are found, this release candidate will be tagged as 23.0. For testing guidance see: https://github.com/bitcoin/bitcoin/issues/24501 -BEGIN PGP SIGNATURE- iQEzBAEBCgAdFiEEnerg3HBjJJ+wVHRoHkrtYphs0l0FAmJUAkwACgkQHkrtYphs 0l11NAf8DcRDKDrbu+7sQCgjSqCbk+9A+T2A7ir1GFK1Sk7in1XYiAaOyM3lP3xf nFO3UYZTv82XSQImQwUgxzZvy75b8X7lLsoFA1I13b3/S2CzY56g9Rlq+SKnWva7 RfoDFGu0rQE4e5c92j29hWSw1parx+AZyOWJZg5IuF6Unq9IYx289/4KGpTLj5vJ UJM3Nh6DxRUmDh8onX2nTcT13jfCm+NsyLFf1gg3fizgbXuBFVPR3Sd++ctI1WIQ /Vf8iRZq2vsCOZlB903Pe+gRUHKCaG4AfdlxTf2Sd2Vhf+etGaazmMWpXYPCUCop JqzIz+EfLw0/2de1BdGQzLhmPMqObA== =XaW1 -END PGP SIGNATURE- ___ bitcoin-core-dev mailing list bitcoin-core-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-core-dev
