SCRIPT⌗

  1. John Newbery talks about verification vs. computation, and he bring it up as a big reason why he thinks bitcoin can scale but is skeptical about ethereum. Is there a qualitative difference between verification and computation? And is it the fact that ethereum is capable of performing arbitrary computation that makes the whole thing difficult to scale, or is it that specifically smart contracts that require arbitrary computation won’t be able to scale (as in those contracts would be very expensive to run)?

    == Output Descriptors

  1. What is the benefit of using output descriptors?

    asd

  2. Are there any use cases for p2sh-wsh-p2pkh descriptors?

    asd

  3. What’s about miniscript? Interactions with descriptors?

    asd

HD Wallets⌗

  1. What is the difference between child and hardened child addresses?

    asd

  2. Why is the internal chain not visible outside of the wallet if it uses public derivation?

    asd

Coin Selection⌗

  1. Is coin age ever a consideration for coin selection?

    asd

  2. Coin selection can expose a wallet by observing how the wallet selects its inputs, are there any efforts to standardize coin selection into a library of sorts so there’s a standard?

    asd

Fee Bumping and RBF⌗

  1. Is there way to ensure that a transaction will be processed? What tools are available to ensure a stuck transaction (due to low fees) gets processed?

    Source material [https://github.com/bitcoinops/scaling-book/blob/add_rbf/1.fee_bumping/fee_bumping.mdhere]

    What’s the problem here? The most common situation is that a transaction was submitted with a low fee-rate such that it is relayed and accepted into the mempool of (most) nodes, but then fee-rate is insufficient to ensure that it is included in a block. The discrepancy arises in that the (standard) mempool size is 300MB deserialised — which is approximately ~110MB worth of serialised transactions — however each block is only 4MB (in weight units) maximum, or more regularly ~1.5MB in size. This effect is compounded because new transactions are always arriving and some of these may be paying higher fees that you, and so your transaction becomes "stuck" in mempool purgatory.

    The reason this can happen is because natively it’s not possible to "bump" a transaction in Bitcoin simply by re-creating it with a higher fee and re-relaying it — nodes will check their mempool and see that spending of these outputs is "accounted for" already, and simply not relay your new, compteitive-fee transaction…​

    Satoshi accounted for the possibility of transaction-replacement in the earliest versions of bitcoin by introducing nSequence numbers of transactions. Incrementing the nSequence number and re-broadcasting the transaction allowed transactions to be replaced. But this approach had some DoS and resouce-exhaustion problems…​ Firstly it did not cost nodes anything to replace a transaction with a incremented nSequence number (they did not have ot have a higher fee), which wasted nodes' bandwidth and CPU in relaying and validating. Secondly replacing a transaction did not ensure that a miner would be any more likely to mine it! For these reasons, Satoshi disable transaction replacement in 2010.:

    Just to reduce surface area. It wouldn’t help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn’t work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.

    — Satoshi Nakamoto

    However, there are a number of options available to you in 2021!:

    1. Direction solicitation of miners:

      This option has always been available. If the transaction is consensus-valid (but not necessarily policy-valid) it is possible to pay a miner directly to include it in a block, or mine a block yourself with the transaction included. If the transaction is the child of another unconfirmed transaction then you’d have to ensure that also got included by paying for the whole "package" to be included.

    2. Replace By Fee (RBF)

      This solves the issue of OG transaction replacement, by only allowing replacement if the transaction has a higher fee than the tx it’s replacing.

      • implication 1: RBF can be used to replace multiple transactions at the same time. That could either be because the replacement transaction is directly replacing two or more original tranasactions by spending their inputs, or because the original transaction that is being replaced has descendants in the mempool which will also need to be removed.

      • implication 2: Additional inputs can be added to the replacement transaction. This is useful if a wallet needs to bump the fee on a transaction but there is no change output to subtract the additional fee from.

      • implication 3: The replacement transaction does not need to include all of the inputs from the original transaction. This can be extremely dangerous since wallets can easily overspend this way. For example, if the original transaction uses inputs A and B, a replacement transaction is sent with inputs B and C, and then that replacement transaction is replaced with a new replacement transaction using inputs C and D, the first transaction could be rebroadcast by a third party at any point in the future, and both would be valid! Wallets are advised to include all inputs from the original transaction in the replacement transaction unless they have very reliable tracking to make sure that they don’t double-spend themselves.

      • implication 4: the nSequence of the inputs in the replacement transaction are not considered, so a replaceable transaction could be replaced by a non-replaceable transaction. If a wallet wants to be able to replace the replacement transaction in future, it must signal opt-in RBF on one of the inputs of the replacement transaction.

        Wallets should be careful to mark transactions with RBF enabled.

    3. Child Pays For Parent (CPFP)

      Where a user spends the output of an unconfirmed (parent) transaction as an input to a new (child) transaction. The wallet attaches enough fee to the child transaction to increase the combined feerate across the parent and child transactions.

      Miners will consider transactions in "packages" if they include ancestors, and the overall fee rate of the "package" is what is used to determine desirability of inclusion of that (package of) transaction(s). You can see the transaction selection in miner.cpp. If miners are using Bitcoin Core for transaction selection users can safely assume that descendant transaction fees will be taken into account when miners construct blocks.

      Wallets need to explicitly support spending un-confirmed outputs, and additionally this might also be an output which did not previously belong to the wallet (i.e. it came from a 3rd party). Bitcoin Core does allow spending unconfirmed change (from it’s own wallet) but spending unconfirmed outputs from a 3rd party is more tightly controlled. (You can see how Bitcoin Core v0.21.0 classifies coins in coins.h).

      If the sender of a transaction wants to bump the fee with CPFP then they need to ensure there’s a change output coming back to themselves, otherwise they have nothing to spend in the child.

      There’s a 25 transaction "package limit" in Bitcoin Core, so bumpers can’t create packages larger than this.

    Also of note: RBF is usually cheaper than CPFP simply because it’s a single transaction vs two transactions.

    + Can you CPFP an RBF transaction?

    + In lightning not having a tx being mined is a security vulnerability, not necessarily bitcoin’s problem.

  2. While inconvenient, could a stuck transaction lead to a loss of funds?

    With lightning possibly! Or anythign with a timelock which can spend aftter a certain amount of time