Re: [bitcoin-dev] Pseudocode for robust tail emission
'only' in this sentence: "only two orders of magnitude higher" - is just like in this one: "We're raising $100,000 for the Tesla S and we're not short of $99,900, we're only short of $99,000..." W dniu 2023-01-22 16:13:42 użytkownik John Tromp via bitcoin-dev napisał: > > Right now the total reward per transaction is $63, three orders of magnitude > higher than typical fees. No need to exaggerate; this is only two orders of magnitude higher than current fees, which are typically over $0.50 ___ 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
With OP_RETURN you publish some data that are immediately visible in the blockchain. I would consider this better (more straightforward) for things like time-stamping. With Taproot you need to spend the utxo to make the script visible. This seems better when you don't want the data public but you need to be able to reveal the data when the time comes. Unless it is important to reveal later, it seems to me that for 80 bytes or less OP_RETURN is still the way to go post-taproot. On Wed, 1 Feb 2023, 04:30 Christopher Allen via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't have a concrete proposal in mind, I'm just trying to understand > various tradeoffs in post-taproot bitcoin in more detail. > > On Tue, Jan 31, 2023 at 6:07 PM Peter Todd wrote: > >> >> >OP_FALSE >> >OP_IF >> >OP_PUSH my64bytes >> >OP_ENDIF >> >> What's wrong with OpPush OpDrop? >> > > I'm not sure pro or con of either. I just saw that proposal above recently. > > >> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The >> whole point of OpReturn is to standardize a way to keep such outputs out of >> the UTXO set. There is the 75% discount to using witness space. But >> considering the size of a transaction as a whole using taproot instead of >> OpReturn doesn't save much. >> > > There are OP_RETURN tricks in production that do clog UTXO space. I was > trying to avoid consideration of those by just saying to compare apples vs. > apples, by presuming that any form of these transactions holding the 64 > bytes is a spent transaction. > > Finally, _64_ bytes is more than a mere 32 byte commitment. What specific >> use case do you actually have in mind here? Are you actually publishing >> data, or simply committing to data? If the latter, you can use ECC >> commitments and have no extra space at all. >> > > I chose 64 bytes for this exercise, as I know there are tricks hiding 32 > bytes as keys. As almost every op_return live out there is >32 bytes, I > wanted an example that could be a signature, two hashes, a hash plus some > metadata, etc. I also considered 96 bytes (for instance a hash and a > signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice > prohibits comparing the different approaches side-by-side. > > To come back to my question another way, if you ignore the people who say > "never put anything except data facilitating coin transactions into the > bitcoin blockchain", but if you also are not trying to use the bitcoin > blockchain as a world database (ala ETH), what is the most pragmatic way to > do so that minimizes any potential harm? The answer pre-taproot was > OP_RETURN. What is it now? > > -- Christopher Allen > ___ > 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] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Could someone clarify what is the standard for OP_RETURN? As far as I understand the data is limited to 80B and only one OP_RETURN is allowed in one transaction, if not the tx is non standard, correct? Then the debate can be to store in witness indeed Or you can store in output addresses (with super big size), then you will never be able to spend the dust and we have a utxo forever In any case there is a storage workaround, probably others exist, not sure why people are so opposed to a OP_RETURN bitcoin storage (I thought the max size was 512B, but apparently I am wrong, 80B is ridiculous, can't do anything with this, except bypassing this limit by other worse means) Storage is the main difference between bitcoin and other systems (ethereum), without it, repeating myself here again the future of bitcoin is very limited PS: I saw the answer of Peter, I am proposing something else for timestamp proofs Le 01/02/2023 à 01:46, Christopher Allen via bitcoin-dev a écrit : > All other things being equal, which is better if you need to place a > 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a > spent taproot transaction such as: > > OP_FALSE > OP_IF > OP_PUSH my64bytes > OP_ENDIF > > I know that the anti-OP_RETURN folk would say “neither.” But if there > was no other choice for a particular protocol, such as a timestamp or > a commitment, which is better? Or is there a safer place to put 64 > bytes that is more uncensorable but also does not clog UTXO space, > only spent transaction `-txindex` space? > > My best guess was that the taproot method is better, but I suspect > there might be some who disagree. I'd love to hear all sides. > > -- Christopher Allen > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -- Sophia-Antipolis, France CV: https://www.peersm.com/CVAV.pdf LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26 GitHub : https://www.github.com/Ayms A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7 A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7 Move your coins by yourself (browser version): https://peersm.com/wallet Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com Peersm : http://www.peersm.com ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote: > > > On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev > wrote: > >All other things being equal, which is better if you need to place a > >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent > >taproot transaction such as: > > > >OP_FALSE > >OP_IF > >OP_PUSH my64bytes > >OP_ENDIF > > What's wrong with OpPush OpDrop? > This is a technical nit, but the reason is that is limited to 520 bytes (and I believe, 80 bytes by standardness in Taproot), so if you are pushing a ton of data and need multiple pushes, it's more efficient to use FALSE IF ... ENDIF since you avoid the repeated DROPs. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
On February 1, 2023 8:36:52 AM GMT, Kostas Karasavvas wrote: >With OP_RETURN you publish some data that are immediately visible in the >blockchain. I would consider this better (more straightforward) for things >like time-stamping. You are incorrect. Time-stamps merely prove that data existed prior to some point in time. There is absolutely no need for anything to be published in the blockchain to create a timestamp. Indeed, efficient timestamps don't actually publish any meaningful data: for efficiency you always combine many timestamps into a single merkle tree; a merkle tree tip digest is meaningless data by itself. OpenTimestamps does in fact use OpReturn rather than something more efficient. But it does this only because the efficiency gain isn't significant enough for me to have gotten around to improving it. Reducing fee costs by ~10% isn't a good use of my time. >With Taproot you need to spend the utxo to make the script visible. This >seems better when you don't want the data public but you need to be able to >reveal the data when the time comes. If your concern is the data being public due to OpReturn vs Taproot, you are confused and need to think more carefully about what exactly you are doing. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
