instagibbs

### Keybase proof

I hereby claim:

  * I am instagibbs on github.
  * I am greg_sanders (https://keybase.io/greg_sanders) on keybase.
  * I have a public key whose fingerprint is 11D4 3A27 826A 4212 1210  8BF6 6BE2 CED1 4A99 17BC

To claim this, I am signing this object:

instagibbs

Collecting ledgerblue
Requirement already up-to-date: pycrypto>=2.6.1 in ./ledger/lib/python2.7/site-packages (from ledgerblue)
Requirement already up-to-date: ecpy>=0.8.1 in ./ledger/lib/python2.7/site-packages (from ledgerblue)
Requirement already up-to-date: future in ./ledger/lib/python2.7/site-packages (from ledgerblue)
Collecting hidapi>=0.7.99 (from ledgerblue)
  Using cached hidapi-0.7.99.post19.tar.gz
Collecting pillow>=3.4.0 (from ledgerblue)
  Using cached Pillow-3.4.2.tar.gz
Requirement already up-to-date: setuptools>=19.0 in ./ledger/lib/python2.7/site-packages (from hidapi>=0.7.99->ledgerblue)
Building wheels for collected packages: hidapi, pillow

instagibbs

shopt -s expand_aliases

rm -r ~/elementsdir1
rm -r ~/elementsdir2
rm -r ~/bitcoindir
mkdir ~/elementsdir1
mkdir ~/elementsdir2
mkdir ~/bitcoindir

instagibbs

shopt -s expand_aliases

rm -r ~/elementsdir1
rm -r ~/elementsdir2
rm -r ~/bitcoindir
mkdir ~/elementsdir1
mkdir ~/elementsdir2
mkdir ~/bitcoindir

instagibbs

diff --git a/src/wallet/rpcdump.cpp b/src/wallet/rpcdump.cpp
index c93c297..bf5655a 100644
--- a/src/wallet/rpcdump.cpp
+++ b/src/wallet/rpcdump.cpp
@@ -811,11 +811,12 @@ struct ImportData
     std::unique_ptr<CScript> redeemscript; //! Provided redeemScript; will be mvoed to `import_scripts` if relevant.
     std::unique_ptr<CScript> witnessscript; //! Provided witnessScript; will be moved to `import_scripts` if relevant.
     std::map<CKeyID, CPubKey> pubkeys;
+    std::vector<CPubKey> ordered_pubkeys; //! Used to track ordering of insertion of pubkeys
     std::map<CKeyID, CKey> privkeys;

instagibbs

# -*- coding: utf-8 -*-

################################################################################
## Form generated from reading UI file 'getxpubdialog.ui'
##
## Created by: Qt User Interface Compiler version 5.14.0
##
## WARNING! All changes made in this file will be lost when recompiling UI file!
################################################################################

instagibbs

<instagibbs> _aj_, thinking I should have two variants of my work, one which is easier to get into signet(but also more pinnable), as well as one that's more "ideal" and can be switched on once features are in. So for MVP for standardness, I think I just need some form of annex relay support
<instagibbs> would be easy to remove EAs, could at least prioritise txns if nothing else as a demo. (or I could hack settlement txns to just dump value to fee)
<instagibbs> Shouldn't be a ton of work on my end to support both variants, and having live demo > not
* Disconnected ()
* Now talking on ##eltoo
<_aj_> instagibbs_: EAs seem fine to keep -- doesn't really matter if there's dust anyone-can-spend utxos on signet due to mempool evictions; all utxos on signet are equally worthless anyway
<instagibbs_> ok, so 1) annexcarrier option which can be arbitrarily restricted later via Bright Side PR 2) Make OP_TRUE output standard 3) allow dusty OP_TRUE. These would be quite low drag and allow me to get txns in the mempool/blo

instagibbs

This was written in response to bitcoin/bitcoin#27578 and any other number of occurrences of the topic.

“Standardness policy” is a term for a transaction that would be consensus-legal, but our node doesn’t want to relay for various reasons. Clearly if it’s consensus valid we want to accept it to not split the network if a miner chooses a “weird” transaction to mine.

There are N motivations for policy that I know of:

1. Anti-DoS: Only “cheap” things to validate get flooded to the network
2. Security: Certain types of transactions may mess up certain systems for no good reason
3. Upgrade hooks: We leave some things “forbidden” such that if we find a use for them later we don’t “confiscate” funds by refusing to relay e.g., a spend or pre-signed transaction
4. Pro-decentralization: Make it simple/cheap for miners to build blocks that pay well

instagibbs

Messaging Changes

I am assuming minimal changes to commitment transaction structure, essentially swapping out HTLC for PTLC, so no fast-forward schemes here.

Here are output labels because I get confused so often what things in BOLTs mean:

• (a) a_o_atx_* Alice-offered "offered PTLC" in Alice's tx
• (b) a_o_btx_* Alice-offered "received PTLC" in Bob's tx
• (c) b_o_atx_* Bob-offered "received PTLC" in Alice's tx
• (d) b_o_btx_* Bob-offered "offered PTLC" in Bob's tx

instagibbs

"Free Relay"

In transaction relay we are trying to avoid "free relay" which is roughly defined as:

total_bytes_relayed / (total_sats_in_mempool + total_sats_mined) ?< minrelay

Did the sum total of bytes we've been accepting to our mempool and propagating across the network pay for the "bandwidth" to do so, dubbed minrelay which is a static value