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

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

diff --git a/src/test/fuzz/package_eval.cpp b/src/test/fuzz/package_eval.cpp
index 9c64c39699..989373b044 100644
--- a/src/test/fuzz/package_eval.cpp
+++ b/src/test/fuzz/package_eval.cpp
@@ -98,51 +98,52 @@ struct TransactionsDelta final : public CValidationInterface {
          m_added.erase(tx);
     }
 };
 
 void MockTime(FuzzedDataProvider& fuzzed_data_provider, const Chainstate& chainstate)

instagibbs

Bitcoin has a KYC problem. We don't know any customers. One man's spammer is another man's marketing genius.

This plays into how Bitcoin software handles transactions that are gossiped to it on the network. Your local node does a list of anti-DoS checks, as well as miner compatibility checks, caches the transaction, and forwards it to any nodes connected to yours.

For miner incentives, this is not exactly straight forward, but easy enough to inuit. If you can "make the mempool better", you accept a new transaction, and kick out whatever it replaced.

This isn't the whole story. What it it makes the mempool contents better for miners, but is worse