Re: [bitcoin-dev] OP_RETURN inside TapScript
> There are two use-cases for OP_RETURN: committing to data, and publishing > data. Your proposal can only do the former, not the latter, and there are > use-cases for both. Only the former is needed. Pushing data on-chain is expensive and that kind of data is useful only to the transaction maker. Also, the latter can be pushed on a separate chain (or even a separate layer that is not a chain at all). Also note that since Taproot we have the latter: we can spend by TapScript and reveal some public key and tapbranches. It is possible to push more than 80 bytes in this way, so why direct OP_RETURN is needed, except for backward-compatibility? (for example in Segwit commitments) There is only one problem with spending by TapScript, when it comes to publishing data: only the first item is the public key. If we could use public keys instead of tapbranch hashes, we could literally replace "OP_RETURN " with " ... ". Then, we could use unspendable public keys to push data, so OP_RETURN would be obsolete. By the way, committing to data has a lot of use cases, for example the whole idea of NameCoin could be implemented on such OP_RETURN's. Instead of creating some special transaction upfront, people could place some hidden commitment and reveal that later. Then, there would be no need to produce any new coins out of thin air, because everything would be merge-mined by default, providing Bitcoin-level Proof of Work protection all the time, 24/7/365. Then, people could store that revealed commitments on their own chain, just to keep track of who owns which name. And then, that network could easily turn on and off all Bitcoin features as they please. Lightning Network on NameCoin? No problem, even the same satoshis could be used to pay for domains! On 2022-03-16 19:21:37 user Peter Todd wrote: > On Thu, Feb 24, 2022 at 10:02:08AM +0100, vjudeu via bitcoin-dev wrote: > Since Taproot was activated, we no longer need separate OP_RETURN outputs to > be pushed on-chain. If we want to attach any data to a transaction, we can > create "OP_RETURN " as a branch in the TapScript. In this way, we > can store that data off-chain and we can always prove that they are connected > with some taproot address, that was pushed on-chain. Also, we can store more > than 80 bytes for "free", because no such taproot branch will be ever pushed > on-chain and used as an input. That means we can use "OP_RETURN <1.5 GB of > data>", create some address having that taproot branch, and later prove to > anyone that such "1.5 GB of data" is connected with our taproot address. There are two use-cases for OP_RETURN: committing to data, and publishing data. Your proposal can only do the former, not the latter, and there are use-cases for both. -- https://petertodd.org 'peter'[:-1]@petertodd.org ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Speedy Trial
> A. Every pollee signs messages like support:10%}> for each UTXO they want to respond to the poll with. It should not be expressed in percents, but in amounts. It would be easier and more compatible with votes where there is 100% oppose or 100% support (and also easier to handle if some LN user would move one satoshi, because rounding percents would be tricky). Anyway, you need to convert percents to amounts, so better use amounts from the very beginning. Also, it could be just some kind of transaction, where you have utxo_id just as transaction input, amount of coins as some output, and then add your message as "OP_RETURN " in your input, in this way your signature would be useless in a different context than voting. Also note that such voting would be some kind of Proof of Stake. And it does not really matter if you store that commitments on-chain to preserve signalling results in consensus rules or if there would be some separate chain for storing commitments and nothing else. It would be Proof of Stake, where users would put their coins at stake to vote. Also, you probably solved "nothing at stake" problem in a nice way, because it would be protected by Proof of Work chain to decide who can vote. So, voters could only freeze their coins for getting some voting power or move their coins and lose their votes. For me, it sounds similar to "Merged Signing" proposed by stwenhao here: https://bitcointalk.org/index.php?topic=5390027.0. I think it is kind of dangerous and unstoppable (so nobody could stop you if you would ignore any criticism and implement that). Fortunately, it is also possible to add some Proof of Work if any staking-like system would be present in Bitcoin, just OP_SUBSTR would do the trick (if enabled; if not, we could still use OP_HASH256 and force the target by some kind of soft-fork on top of your voting system). On 2022-03-17 20:58:35 user Billy Tetrud via bitcoin-dev wrote: @Jorge > Any user polling system is going to be vulnerable to sybil attacks. Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components: A. Every pollee signs messages like for each UTXO they want to respond to the poll with. B. A signed message like that is valid only while that UTXO has not been spent. C. Poll results are considered only at each particular block height, where the support and opposition responses are weighted by the UTXO amount (and the support/oppose fraction in the message). This means you'd basically see a rolling poll through the blockchain as new signed poll messages come in and as their UTXOs are spent. This is not vulnerable to sybil attacks because it requires access to UTXOs and response-weight is directly tied to UTXO amount. If someone signs a poll message with a key that can unlock (or is in some other designated way associated with) a UTXO, and then spends that UTXO, their poll response stops being counted for all block heights after the UTXO was spent. Why put support and oppose fractions in the message? Who would want to both support and oppose something? Any multiple participant UTXO would. Eg lightning channels would, where each participant disagrees with the other. They need to sign together, so they can have an agreement to sign for the fractions that match their respective channel balances (using a force channel close as a last resort against an uncooperative partner as usual). This does have the potential issue of public key exposure prior to spending for current addresses. But that could be fixed with a new address type that has two public keys / spend paths: one for spending and one for signing. > In perfect competition the mining power costs per chain tends to equal the > rewards offered by that chain, both in subsidy and transaction fees. Agreed, but it takes time for an economic shock to reach its new equilibrium. That period of time, which might be rather precarious, should be considered in a plan to preserve a minority fork. > Would you rather that proposal be deployed with speedy trial activation or > with BIP8+LOT=true activation? For a proposal I don't want to succeed, I absolutely would prefer speedy trial over BIP8+LOT=true. Speedy trial at 90% signaling threshold can quickly determine that the proposal (hopefully) does not have enough consensus among miners. By contrast, BIP8+LOT=true could polarize the debate, worsening the community's ability to communicate and talk through issues. It would also basically guarantee that a fork happens, which in the best case (in my hypothetical point of view where I don't like the proposal) would mean some small minority forks off the network, which reduces the main chain's value somewhat (at least temporarily). Worst case a small majority forces the issue at near 50% which would cause all sorts of blockchain issues and would have a high probability of leading to a
Re: [bitcoin-dev] bitcoin scripting and lisp
On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj wrote: > My point is that in the past we were willing to discuss the complicated > crypto math around cross-input sigagg in order to save bytes, so it seems > to me that cross-input compression of puzzles/solutions at least merits a > discussion, since it would require a lot less heavy crypto math, and *also* > save bytes. > When using BLS signatures all that math is much simpler. You use a single aggregated signature and always aggregate everything all the time. I think there are two costs here: > > * Cost of bytes to transmit over the network. > * Cost of CPU load. > There are three potential costs: CPU, bytes, and making outputs. In Chia it's balanced so that the costs to a standard transaction in all three buckets are roughly the same. In Bitcoin the three are implicitly tied to each other by design which makes vbytes work okayish for Bitcoin Script as it exists today. > It seems to me that lisp-generating-lisp compression would reduce the cost > of bytes transmitted, but increase the CPU load (first the metaprogram > runs, and *then* the produced program runs). > Nah, CPU costs are dominated by signatures. Simple operations like applying some parameters to a template don't add much. > Not being a mathist, I have absolutely no idea, but: at least as I > understood from the original mimblewimble.txt from Voldemort, BLS > signatures had an additional assumption, which I *think* means > "theoretically less secure than SECP256K1 Schnorr / ECDSA". > Is my understanding correct? > And if so, how theoretical would that be? > It includes some an extra cryptographic assumption but it's extremely theoretical, having more to do with guessing what size of group provides comparable security in number of bits than whether the whole approach is in question. BLS12-381 is fairly conservative. > > PTLC signatures have the very nice property of being indistinguishable > from non-PTLC signatures to anyone without the adaptor, and I think > privacy-by-default should be what we encourage. > You do lose out on that when you aggregate. > > I'm not sure that a "covenant language implementation" would necessarily > > be "that" complicated. And if so, having a DSL for covenants could, > > at least in theory, make for a much simpler implementation of > > ANYPREVOUT/CTV/TLUV/EVICT/etc than doing it directly in C++, which > > might mean those things are less likely to have "weird surprises" rather > > than more. > > > DSLs? > Domain-specific languages? > Bitcoin Script is already a domain specific language, and the point of adding in a lisp-family language would be to make it so that covenants and capabilities can be implemented in the same language as is used for regular coin scripting. The idea is to get off the treadmill of soft forking in language features every time new functionality is wanted and make it possible to implement all that on chain. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
