Re: [bitcoin-dev] Bitcoin Transaction Relay over Nostr
Hi Joost, David, In my mind, weak blocks' main benefit would be that it improves block relay by giving PoW-hints on what are in miner's mempools. Non-standard transactions could even be cached(even if not validated until block inclusion), which would tolerate more heterogeneity in policies without drastically increasing relay times. Of course, it can also have the side effect of gossiping better transaction packages, though I think this would be a ton of work to really take advantage of. Perhaps we might be able to do better in a post-cluster-mempool world, gossiping chunks. At present I think energy would be best spent writing a weak blocks BIP proposal, since one has never been written before(?), and it would be fairly trivial to swap out p2p things with RPC calls if so desired for fast experimentation over alternative relays. Cheers, Greg On Tue, May 30, 2023 at 8:58 AM Joost Jager via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi David, > > >> A block template is an ordered list of raw transactions that can all be >> included in the next block (with some space reserved for a coinbase >> transaction). A full node can validate those transactions and calculate >> how much fee they pay. A Nostr relay can simply relay almost[1] any >> template that pays more fees than the previous best template it saw for >> the next block. That can be more flexible than the current >> implementation of submitblock with package relay which still enforces a >> lot of the rules that helps keep a regular relay node safe from DoS and >> a miner node able to select mineable transactions quickly. >> > > Interesting idea! This would also make it easy for external services to > try to do the best possible block building using advanced algorithms. > Miners would just select the best template available from various sources > including nostr. > > >> A weak block is a block whose header doesn't quite hash to low enough of >> a value to be included on the chain. It still takes an extraordinary >> amount of hashrate to produce, so it's inherently DoS resistant. If >> miners are producing block that include transactions not seen by typical >> relay nodes, that can reduce the efficiency and effectiveness of BIP152 >> compact block relay, which hurts the profitability of miners of custom >> blocks. To compensate, miners could relay weak blocks through Nostr to >> full nodes and other miners so that they could quickly relay and accept >> complete blocks that later included the same custom transactions. This >> would also help fee estimation and provide valuable insights to those >> trying to get their transactions included into the next block. >> > > I believe this would be useful right away, wouldn't it? Looking at > mempool.space's block audit, there are definitely blocks that have a > "surprising" content and might take long to download. > > The anti-dos measures that you describe for both weak blocks and block > templates seem very robust, but they would require a more intelligent nostr > relay to enforce. Not sure if it is still allowed to call it nostr at that > point. Perhaps it becomes more of a specialised bitcoin relay. btcstr - > "bitcoin stuff transmitted by relays". > > Regarding size, the block template and weak block could both be sent in >> BIP152 compact block format as a diff against the expected contents of a >> typical node, allowing Alice to send just a small amount of additional >> data for relay over what she'd have to send anyway for each transaction >> in a package. (Although it's quite possible that BetterHash or Stratum >> v2 have even better solutions, possibly already implemented.) >> > > Sounds like a great way to repurpose what already exists to reduce > resource usage for these additional message types. > > >> If nothing else, I think Nostr could provide an interesting playground >> for experimenting with various relay and mining ideas we've talked about >> for years, so thanks again for working on this! >> > > I think so too! The main question on my mind though is how to actually > make this work. There is a bit of a chicken-egg problem here with users and > miners possibly waiting for each other to adopt. > > Joost > ___ > 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] Bitcoin Transaction Relay over Nostr
Hi David, > A block template is an ordered list of raw transactions that can all be > included in the next block (with some space reserved for a coinbase > transaction). A full node can validate those transactions and calculate > how much fee they pay. A Nostr relay can simply relay almost[1] any > template that pays more fees than the previous best template it saw for > the next block. That can be more flexible than the current > implementation of submitblock with package relay which still enforces a > lot of the rules that helps keep a regular relay node safe from DoS and > a miner node able to select mineable transactions quickly. > Interesting idea! This would also make it easy for external services to try to do the best possible block building using advanced algorithms. Miners would just select the best template available from various sources including nostr. > A weak block is a block whose header doesn't quite hash to low enough of > a value to be included on the chain. It still takes an extraordinary > amount of hashrate to produce, so it's inherently DoS resistant. If > miners are producing block that include transactions not seen by typical > relay nodes, that can reduce the efficiency and effectiveness of BIP152 > compact block relay, which hurts the profitability of miners of custom > blocks. To compensate, miners could relay weak blocks through Nostr to > full nodes and other miners so that they could quickly relay and accept > complete blocks that later included the same custom transactions. This > would also help fee estimation and provide valuable insights to those > trying to get their transactions included into the next block. > I believe this would be useful right away, wouldn't it? Looking at mempool.space's block audit, there are definitely blocks that have a "surprising" content and might take long to download. The anti-dos measures that you describe for both weak blocks and block templates seem very robust, but they would require a more intelligent nostr relay to enforce. Not sure if it is still allowed to call it nostr at that point. Perhaps it becomes more of a specialised bitcoin relay. btcstr - "bitcoin stuff transmitted by relays". Regarding size, the block template and weak block could both be sent in > BIP152 compact block format as a diff against the expected contents of a > typical node, allowing Alice to send just a small amount of additional > data for relay over what she'd have to send anyway for each transaction > in a package. (Although it's quite possible that BetterHash or Stratum > v2 have even better solutions, possibly already implemented.) > Sounds like a great way to repurpose what already exists to reduce resource usage for these additional message types. > If nothing else, I think Nostr could provide an interesting playground > for experimenting with various relay and mining ideas we've talked about > for years, so thanks again for working on this! > I think so too! The main question on my mind though is how to actually make this work. There is a bit of a chicken-egg problem here with users and miners possibly waiting for each other to adopt. Joost ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Encrypted (like BIP38) master private key
Just like we have BIPP38 encrypted keys for singular private keys, I was wondering if it would be possible to come up with a way to encrypt an extended private key using reversible encryption. BIP38 was designed with physical coins in mind, and in particular covers the cases for lot and sequence numbers in detail. There is a case to be made that in an encrypted extended private key, the lot and sequence numbers can be placed in the HD derivation path. In particular they can be derived like this: m/lot'/sequence' and both of them use hardened derivation. The advantage would be that coinmakers would only have to generate one master private key during manufacturing instead of a ton of private keys. But this is not a very convincing advantage so I'd like to hear what is other people's take on this. -Ali___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Merkleize All The Things
I should clarify: the current proposal already achieves the first part needed for coin pools: removing some data from the merkle tree (I was indeed referring to the embedded data, not the taptree). The thing that is missing is removal of a public key from the taproot internal key, but as mentioned I do agree that this is out of scope for this proposal. I believe you can get many of the benefits by falling back to "old style multisig" in case someone exits the pool, by having a tap leaf defining a multisig check amongst the remaining pubkeys. Cheers, Johan > It seems likely that efficient use of the taproot internal pubkey with > "dynamic key aggregation" is not possible with the current semantics > (unless one ventures into the fraud proof machinery, which seems > overkill!). > > However, in constructions with MATT opcodes, I would never expect the > need for data to be stored in the taptree. In particular, for the case > of CoinPools, the pubkeys of the members could also be stored in the > embedded data, having a single "unilateral withdrawal" tapleaf. > Removing a key would then amount to replacing it with a fixed NUMS key > and computing the new root (re-using the same Merkle proof). > Note that this is not a lot costlier than using a tapleaf per user: > instead of paying the cost for the Merkle proof in the control block, > you pay for it explicitly in the Script witness. > > Therefore, I would expect there to be reasonable CoinPools designs > without additional opcodes − but I am only moderately confident as > this is beyond the level of sophistication I've been exploring so far. On Sun, May 28, 2023 at 12:24 PM Salvatore Ingala wrote: > > Hi Johan, > > Exciting to finally see some merkleization, which was only confined > within the meme, up to this point! > > > A simpler way IMO, would be to make OP_CICV and OP_COCV symmetrical: > > Have OP_CICV take an optional taproot and do the same check as is > > done for the output: Q == tweak(tweak(X,D), T). > > I think that's an excellent suggestion, which I was already exploring > for a different purpose: bringing externally signed data onto the > stack. My goal there was to allow eltoo-style replacement. > > Until recently, I thought that a clean/efficient version of eltoo > would require OP_CHECKSIGFROMSTACK or ANYPREVOUT. However, extending > OP_CHECKINPUTCONTRACTVERIFY to enable introspection of other inputs > allows a reasonable workaround: producing a separate UTXO signed with > ANYONECANPAY, with the required data embedded as usual. Spending that > UTXO together with the channel's UTXO allows one to get that data > on the stack (with its signature already checked by consensus rules). > I drafted this idea in a gist [1]. > > Remark: it still seems easier (and probably slightly more efficient) > to build eltoo replacement with CSFS or APO in addition to MATT > opcodes. > > A possible semantics for OP_CHECKINPUTCONTRACTVERIFY could then be > exactly symmetrical to that of OP_CHECKOUTPUTCONTRACTVERIFY, with > the exception that the special input index -1 would represent the > current input. > > Pushing this further, another option that could be be worth exploring > is to have a single OP_CHECK_IN_OUT_CONTRACT_VERIFY opcode, with the > same semantics as OP_CHECKOUTPUTCONTRACTVERIFY from [2], but with an > additional `flags` argument, which is a bitmap where: > - the lowest-significant bit determines if the index refers to inputs > or outputs (where input index -1 refers to the current input) > - the second bit specifies if amounts should be preserved with > deferred checks as described in [2] (only applicable to outputs) > - other bits are OP_SUCCESS and reserved for future behaviors. > > This would make the opcodes 1-2 bytes larger, but might allow greater > flexibility, and keep some room for future extensions. > > > 2.To make fully functioning CoinPools, one would need functionality > > similar to OP_MERKLESUB[4]: remove some data from the merkle tree, > > and remove a key from the aggregated internal key. > > It seems likely that efficient use of the taproot internal pubkey with > "dynamic key aggregation" is not possible with the current semantics > (unless one ventures into the fraud proof machinery, which seems > overkill!). > > However, in constructions with MATT opcodes, I would never expect the > need for data to be stored in the taptree. In particular, for the case > of CoinPools, the pubkeys of the members could also be stored in the > embedded data, having a single "unilateral withdrawal" tapleaf. > Removing a key would then amount to replacing it with a fixed NUMS key > and computing the new root (re-using the same Merkle proof). > Note that this is not a lot costlier than using a tapleaf per user: > instead of paying the cost for the Merkle proof in the control block, > you pay for it explicitly in the Script witness. > > Therefore, I would expect there to be reasonable CoinPools designs > without additional opcodes − but I am
