I mean everyone. The point is that politically, the Bitcoin ecosystem should not accept imposed rule-changes on the network. And so, a hard-fork that comes out of a closed-door meeting sounds like an imposed rule change on the network. There are many people who will principally reject this, reflexively. I want there to be collaboration. Most people will ignore it. But I want there to be collaboration so that we can say this is a product of the Bitcoin community. It cannot be a closed-door agreement.

At this point, it would be a little bit difficult or challenging to reframe the HK agreement to a broader community-based effort. Trying to reframe the HK agreement to an open community agreement would be difficult. The simplest way is to, we just based on the HK agreement, then we try to pull people into that and then gain consensus on that. That would be the simplest way.

# Taproot

There is, however, a problem with MAST which is that MAST inputs are obvious. You're doing a MAST payment. There's a proposal called taproot. This is why you check twitter during talks. It uses a new style of pay-to-pubkeyhash. You can-- the users, when they are setting this up, use a base key and a hash of a script that they want the alternative to be. They use that to make a new key, then they just say use this new thing and pay to that key. They can pay using key and signature like before. Or you can reveal the base key and the script, and it will execute the script for you. In the common case, it looks like pay-to-pubkeyhash which helps fungibility. In the exceptional case, you provide the components and you can do MAST. This overrides what I had said earlier about MAST coming soon because this proposal looks really awesome but taproot doesn't have any code yet.

<http://diyhpl.us/wiki/transcripts/gmaxwell-confidential-transactions/>

Enough about scrips for a moment. The blockchain is public. In particular, the amounts are public, and this actually reveals a lot of information. By looking at the amounts, you can often tell which one is a change output and going back to the same person. All that nodes really need to know is not necessarily the amounts, but rather that there is no inflation in the system. They only need to know that the sum of the input amounts is equal to the sum of the output amounts plus the miner fee amount. They also need to kknow that there was no overflow. You don't want a 1 million BTC transaction and a -1 million BTC transaction.

# Rolling UTXO set hashes

Another subset of the UTXO set problem is that there's no compact way to prove that UTXO set is correct. XORing all the UTXOs together is not secure. There's this idea of a rolling UTXO set hash. You can update a 256-bit number, it's fairly easy to calculate, you can update this one hash when a new block comes in. If you're a full node, you can record your UTXO set hash and then validate that your UTXO set hasn't been corrupted. But it also helps the idea of initial node bootstrap and initial block download. If you get TXO hash from someone you trust, say someone writing the bitcoin software, you can go anywhere and get the UTXO set, and you can download it, and just check that the hash matches. Maybe if things keep getting bigger, then this might be a middle ground between running a lite node and running a fully-validating full node from the dawn of time itself.

# NODE\_NETWORK\_LIMITED (bip159)

<https://github.com/bitcoin/bips/blob/master/bip-0159.mediawiki>

* <https://bitcoinops.org/en/newsletters/2018/12/04/>

* <https://bitcoinops.org/en/newsletters/2018/12/11/>

Minisketch: an optimized library for BCH-based set reconciliation <https://github.com/sipa/minisketch>

* Russell O'Connor, Marta Piekarska: [OP\_CHECKSIGFROMSTACK](https://fc17.ifca.ai/bitcoin/papers/bitcoin17-final28.pdf) and <https://blockstream.com/2016/11/02/covenants-in-elements-alpha/>

Eyal, Sirer and Moser wrote a paper in 2016 and showed it at Financial Crypto 2016. They proposed a new opcode OP\_CHECKOUTPUTVERIFY.

The way this works is that when you do EC recovery on a signature, you have three things really-- you have a signature, a pubkey, and you've got a message. Those are the three things involved in verifying a signature. The pubkey and signature are obvious to everyone here right? The message here is really the SIGHASH. It's a concatenation of a whole bunch of data extracted from the transaction. It depends on the version, hash of the previous outputs, and the outputs, and various other things. The signature authorizes that. What we want to do is not depend on the pubkey in the input. That creates a circular dependency where you can't do EC recovery.

# Schnorr BIP and SIGHASH\_NOINPUT discussion

# Related

<https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better>

<https://bitcointalk.org/index.php?topic=5111656>

<http://web.archive.org/web/20180503151920/https://blog.sldx.com/re-imagining-cold-storage-with-timelocks-1f293bfe421f?gi=da99a4a00f67>

<https://www.youtube.com/watch?v=HEZAlNBJjA0&t=1h>

If we start with the segregated witness soft-fork, we can get approximately 2 MB as wallets and companies opt-in, and that's in current late-stage testing. The last testnet before production is running right now, I think segnet4. That should be relatively soon if the ecosystem wants to activate it and opt-in and start adopting it to achieve scale and the other fixes it comes with.

# HTLC: stuck payments

# Schnorr Taproot HTLC: cancellable payments

Q - You said Lightning has privacy guarantees on its protocol but developers should make sure they don’t ruin the privacy guarantees on top of the base Lightning protocol. Do you see a tendency that applications are taking shortcuts on Lightning and ruining the privacy?

Signet on Bitcoin Wiki: https://en.bitcoin.it/wiki/Signet

Bitcoin Core PR 16411 (closed): https://github.com/bitcoin/bitcoin/pull/16411

Say you are doing SSS over a master private key. With each shard, we generate a partial signature over a transaction. A Schnorr signature is the sum of this random point plus the hash times the private key, and it's linear. We can apply the same function to recombine the signature parts. We can apply the same function to s1, s2 and s3 and then you get the full signature S this way without ever combining the parts of the keys into the full key.

I was thinking about using miniscript policies to unlock the secure element. To unlock the secure element, you could just use a PIN code or you could use it in a way where you need signatures from other devices or one-time codes from some other authentication mechanism. We needed to implement miniscript anyway. We're not restricted to bitcoin sigop limits or anything here; so the secure element should be able to verify this miniscript script with whatever authentication keys or passwords you are using. It can even be CHECKMULTISIG with the 15 key limit removed.

<https://bitcoinops.org/en/newsletters/2019/07/31/>

Fidelity bonds for providing sybil resistance to joinmarket. Has anyone used joinmarket before? No? Nobody? Nice try... Right. So, joinmarket is a wallet that is specifically designed for doing coinjoins. A coinjoin is a way to do a little bit of mixing or tumbling of coins to increase the privacy or fungibility of your coins. There's a few different options to it. It essentially uses IRC chatbots to solicit makers and takers. So if you really want to mix your coins, you're a taker, and a maker on the other side puts up funds to mix with your funds. So there's this maker/taker model which is interesting. I haven't used it, but it looks to be facilitated by IRC chat. The maker, the person putting in money, doesn't necessarily need privacy, makes a small percentage on their bitcoin. It's all done with smart contracts, and your coins aren't at risk at any point, except in as much that they are stored in a hot wallet to interact with the protocol. The sybil resistance that they are talking about here is that, so, Chris Belcher has a great privacy entry on the bitcoin wiki so check that out sometime. He's one of the joinmarket developers. He notices that it costs very little to flood the network with a bunch of makers if you're a malicious actor, and this breaks privacy because the chances of you running into a malicious or fraudulent chainalysis type company, it's not that they can take your coins, but they would be invading your privacy. The cost of them doing this is quite low, so the chances of them doing this is quite high as a result.

# Newsletter 57: Bloom filter discussion

<https://github.com/bitcoin/bitcoin/issues/16152>

Cool, thanks for describing that.

<https://www.coindesk.com/the-vault-is-back-bitcoin-coder-to-revive-plan-to-shield-wallets-from-theft>

## OP\_CHECKTEMPLATEVERIFY

This is Jeremy Rubin's work. The idea is that it's a covenant proposal for bitcoin. The idea is that the UTXO can only... ((bryan took this one)). This workshop is going to be at the end of the month. Says he is going to sponsor people so if you're into this then consider it. Because it can be self-referential, you can have accidental turing completeness. The initial version had this problem. It might also be used by exchanges on withdrawal transactions to prevent or blacklist your future transactions.

# TXHASH + CHECKSIGFROMSTACKVERIFY

Taproot activated recently. People are asking, what's next? Some people were asking about CTV and ANYPREVOUT. There's a heated discussion with drama lately. Then Russell O'Connor dropped a bomb about TXHASH + CHECKSIGFROMSTACKVERIFY which kind of lets you do both things in a single proposal. Well, kind of.

# CTV improve DLCs

DLCs are discrete log contracts. It's like a way to do DeFi on bitcoin. An oracle attests to an event and then you can form a bitcoin transaction on that and change the outcome based on what the oracle signs. You can do the same thing in bitcoin using adaptor signatures. For my super bowl bet, we had three transactions based on the possible outcomes. We had a signature for each of them, the oracle posted an event and when that oracle signature goes out they make one of the transactions valid and then it completes. Three outcomes is pretty simple, but with the bitcoin price there's technically infinite outcomes for what it could be but there's still millions of signatures required in DLCs. It's a nightmare.

# CTV signet

There is now a signet for CTV that behaves in a more predictable manner. If you want to play around with it, you can test it on this signet.

# Replace-by-fee

We have like 10 minutes left; we can keep talking about this, but I want to move on to RBF. If the network looks like this in 10 years, then you could argue that bitcoin has failed. We need to be paying transaction fees. The base layer needs to have utility. We need to figure out how to deal with this stuff. There were two debates on the mailing list that were super interesting recently. This is back to bitcoin layer 1 which implicates lightning though because we're talking about these second layer protocols that rely on previously signed transactions because paying for fees is really difficult...

# Fee bumping

jamesob started a thread; he was noting that, wow this is complex. Why are we spending so much effort throwing in hacks? The way he described it is that CPFP and RBF are hacks because we're not dealing with fees in a sensical way for the way we're doing transactions today. The foundational problem being identified in all of these discussions is that right now when you're paying for fees, you're paying for fees- the entity paying for fees is the same thing that the fees are paying for. So a transaction has to pay for its own fees, and the propisition is... if you have a transaction you're setting in stone for lightning network for example where you don't know what the fee market is going to be in a few years if you're talking about inheritance protocols... you might be locking in too high of a fee or too low of a fee. jamesob gets into this; you should be able to pay separate from that thing you're paying for, so that you can prepare the transaction ahead of time and say okay I've signed and committed to spending these utxos; when I'm ready to broadcast it, then that's when I should decide how much to pay. This harkens back to transaction sponsors where you publish another transaction at the time that says I want to pay for this other transaction and if it doesn't get in then don't take my utxos to pay for that.

# Quantum protections for post-quantum taproot commitment

Today bitcoin uses the discrete log assumption. If quantum computers become a real thing, then they can break all the keys in bitcoin and we'd all lose all of our money. It would suck. Well, only the public keys that are fully public which is most of the keys... the nice thing is that we could have a way to do quantum signatures. The general cryptography space is moving towards this. SSH recently released something for quantum signatures. It's happening outside of bitcoin; it's not just bitcoin worried about this.

# Blind signing risks

We're going to skip this segment.

# Wallet policies for descriptor wallets

# Descriptors

The proposal is to add a ; semicolon inside of a descriptor to say it could be 0 or 1 at this part in a path. It's an optimization of how to describe a wallet. Can it be an array or is it only two options? There's no really interesting use case where you want the exact same ... if you have multiple accounts...

# Wallet label BIP

If you export a wallet to a new device or wallet, one thing you lose is the context or labels from your wallet. In this BIP, he is proposing a CSV-based export. In the comments, Trezor came back and said no there's already a json version of this please don't reinvent the wheel. "We have a standard that only we use".

# Lightning fee rate cards

I could talk about this a little bit. I gave a presentation bitcoin++ on these. This is a mailing list post which is apparently how things get done in bitcoin. There's this idea in lightning for a long time that it would maybe be a nice interesting thing if we would be able to have negative rates for channels on lightning. It has to do with lightning and liquidity and pricing of that liquidity. Right now there's really only positive prices so you can charge people money to send or forward a payment and you advertise what that rate is. This is a proposal for what we might want to do to change to make it so that the way we advertise rates in such a way that you could make it possible to advertise negative rates and not completely kill the lightning gossip network. The idea is that if you take the ... there is this proposal from a few weeks ago where why not make it so that you can have negative rates in lightning? Take the existing thing and make the number go negative, right? The problem with this is that you probably don't want to set all your liquidity at a negative rate, and you might want to update it quickly, and now the gossip on the lightning network becomes a lot and now gossip will have a monetary value in a way that it currently does but right now-- negative numbers would mean you get paid to send payments. So having up to date information about where the negative fees are would be a competitive advantage for payments because you could get paid to send payments so that probably wouldn't be a good idea. This is a proposal now for how to put gossip, and let people have negative rates for a certain amount of the liquidity in their channel. The other cool thing about this is that it's a dynamic pricing scheme that is done in a static way so in theory we could significantly reduce the amount of gossip getting put out on the network when balances and channels change. Right now sometimes balances update and then gossip gets updated; so anyway, there's a lot of gossip. This is one proposal for how to change advertising fee rates. This started off simple: how do we get negative rates on lightning? But when you think about it, a lot more complexity emerges. Rene Pickhardt is a data scientist that knows a lot of math and he likes building models about how things flow through the lightning network. His most recent thing is this "price of anarchy" stuff which is a way of calculating the Tragedy of the Commons except in mathy terms. He had a counter proposal where he proposed pricing stuff based on how large your HTLCs are instead of what percent of your liquidity, but larger HTLCs are inherently more expensive because you pay more the higher you... anyway, this is cool. The thing about advertising this data is that, it's an interesting thing is that, in terms of upgading gossip with data. Fee rate cards is like publishing information and it lets people publish more granular information about how they validate liquidity in their channel. You can add that to a protocol. Instead of writing new routing algorithms, you can take this information and use it in their route planning. I think this will get into the advertising side, and then maybe eventually people will start doing interesting routing things with that data. I think that having negative fees might increase arbitrage on liquidity on lightning which might make a new game to play on lightning.

The way that signatures work in bitcoin is that you don't sign the whole data structure. You take a hash of the subset of the transaction and sign that. The signature has a flag for which kinds of things you are taking into consideration in your signature, so that someone else can validate the transaction. You could come up with interesting protocols around changing what you're going to sign. There was a recent proposal earlier this year for TXHASH that would have flags about every little item in the transaction that you could commit to.

A: Okay, I'm not going to type that into Google.

# Batch validation of CHECKMULTISIG using an extra hint field

Bitcoin multisig has a bug where it incorrectly pops an extra item off the stack which means the script will fail unless you put a nulldummy or a zero at the start. You say 2-of-3 multisig and then it tries to get 3 signatures off the stack which is obviously wrong. Off-by-one errors are always the hardest to deal with, right.

# Ephemeral Anchors

This solves rule 3 and rule 5... No, it doesn't solve it for everything. It's for a small subset. Also it's opt-in. It's not a general solution. Why make it more complex? Make everything replaceable. At some level, most miner incentive compatible thing is to let anyone bid on re-bid on transactions. This is a whole separate topic. I'm sorry.

# Replacement for APO + CTV

The guy who wrote this is - I think this was born out of a frustration from people who want APO vs who want CTV don't need to be at odds. It's a manufactured conflict. APO is ANYPREVOUT and CTV is CHECKTEMPLATEVERIFY. They were two separate proposals that introduced covenants in different ways.

# Bitcoin-like script symbolic tracer

Bitcoin script is kind of hard to read. It's hard to parse. Basically this tool... the idea is that you put in a script, they have a fancy one here in the email, I don't know what that script does but he says this tool will create a tree of possible case that could happen so that you can check are there any edge cases or anything. It traces down every single possible path and so like, he has, he put this fancy script and says.. the first IF branch will always fail, so then you can remove that one. The analysis report will show the possible outcomes. You can parse out everything that can happen in the script including success conditions and fail conditions.

# Scaling lightning with simple covenants

A lot of CTV motivations is for things like OP\_VAULT. But there are not a lot of talk yet for using CTV for scalability. So here they are talking about how to use covenants to scale Lightning. Right now you have to be online and share a UTXO between people. Lightning won't scale if every single person needs to do that. So we need a way to share UTXOs between people.

# bitcoin-dev mailing list

<https://twitter.com/kanzure/status/1721915515520659510>

# Merkleized abstract syntax trees (MAST)

I am going to talk about the scheme I posted to the mailing list yesterday which is to implement MAST (merkleized abstract syntax trees) in bitcoin in a minimally invasive way as possible. It's broken into two major consensus features that together gives us MAST. I'll start with the last BIP.

If you don't mind the exponential blow-up, then all things reduce to "long list of ways to unlock this, pick one". The exponential blow-up in a merkle tree turns into a linear blow-up in ways to unlock things, but still exponential work to construct it.

The outer version is the hash type or explaining what the hashes are. So the history behind this is that at some point we were thinking about these ... recoverable hashes which I don't think anyone is seriously considering at this point, but historically the reason for extending the size ... I think my idea at the time when this witness versioning came up, we only need 16 versions there because we only need the version number for what hashing scheme to use. You don't want to put the hashing version inside the witness which is constrained by that hash itself because now someone finds a bug and writes ripemd160 and now there's a preimage attack there and now someone can take a witness program but claim it's a ripemd160 hash and spend it that way. So at the very least the hashing scheme itself should be specified outside the witness. But pretty much everything else can be inside, and I don't know what structure that should have, like maybe a bitfield of features (i am not serious about this), but there could be a bit field that has the last two are hashed, into the program.

So merklebranchverify maybe should be deployed with the non-SegWit version.. but maybe that would send a conflicting message to the users of bitcoin. Segwit's cleanstack rule prevents us from doing this immediately. Only in v0.

They can break a CHECKSIGFROMSTACK... in a hard-fork. CHECKBLOCKHASH has other implications, like transactions aren't-- in the immediately prior block, you can't reinsert the transaction, it's not reorg-safe. It should be restricted to like 100 blocks back at least.

[a]I approve this chatham house rule violation

----

<https://www.reddit.com/r/Bitcoin/comments/7p61xq/the_first_mast_pull_requests_just_hit_the_bitcoin/>

Draft of an upcoming scriptless scripts paper. This was at the beginning of 2017. But now an entire year has gone by.

An adaptor signature.. if you have different generators, then the two secrets to reveal, you just give someone both of them, plus a proof of a discrete log, and then you say learn the secret to one that gets the reveal to be the same. It's a proof of equivalence discrete log. You decompose a secret key into bits. For these purposes, it's okay to have a 128-bit secret key, it's only used once. 128 bits is much smaller than secp and stuff. We can definitely decompose it into bits. You need a private key, but lower than the group ordering in both. I am going to treat the public key... I'm going to assume-- it's going to be small enough, map from every integer into a range, bijection into the set of integers and set of scalars in secp and the set of scalars in... It's just conceptually because otherwise it doesn't make sense to do that. In practice, it's all the same numbers. You split it into bits, similar to the Monero Ring-CT thing, which is an overly complicated way to describe it. What about schnorr ring signatures? Basically, the way this works, a Schnorr signature has a choice of a nonce, you hash it, then you come up with an S value that somehow satisfies some equation involving the hash and the secret nonce and the secret key. The idea is that because the hash commits to everything including the public key and the nonce, the only way you can make this equation work is if you use -- the secret key-- and then you can compute S. And if hte hash didn't commit, then you could just solve for what the public nonce should be. But you can't do that because you have to choose a nonce before a hash. In a schnorr ring signature, you have a pile of public keys, you choose a nonce you get a hash, but then the next key you have to use that hash but the next key, and eventually you get bcak to the beginning and it wraps around. You start from one of the secret keys, you start one key passed that, you make up random signatures and solve them and go back, and eventually you can't make a random signature and solve it, and that's the final hash, which is already determined, and you're not allowed to make it again, you have to do the right thing, you need a secret key. The verifier doesn't know the order, they can't distinguish them. What's cool about this is that you're doing a bunch of algebra, you're throwing some shit into a hash, and then you're doing more algebra again and repeating. You could do this as long as you want, into the not-your-key ring signature, you just throw into random stuff into this hash. You could show a priemage and prove that it was one of those people, it's unlinkability stuff. You could build a range proof out of this schnorr ring signature. Suppose you have a pedersen commitment between 0 and 10, call it commitment C. If the commitment is 0, then I know the discrete log to C. If the commitment is to 1, then I know C - H, and if it's 2 then it's C-2H, and then I make a ring with C - H, up to C-10H, and if the range is in there, then I will know one of those discrete logs. You split your number into bits, you have a commitment to either 0, 1, or 0, 2, or 0, 4, or 0, 8, and you add all of these up. Each of these individual ring signatures is linear in the number of things. You can get a log sized proof by doing this. These hashes-- because we're putting points into these hashes, and hashes is just using this data. I can do a simultaneous ring signature where every state I'm going to share a hash function, I will do both ring signatures, but I'm using the same hash for both of them, so I choose a random nonce over here, I hash them both, and then I compute an S value on that hash on both sides, I get another nonce and I put both of those into the next hash, and eventually I'll have to actually solve on both sides. So this is clearly two different ring signatures that both are sharing some.... But it's true that the same index.. I have to know the secret key of the same index on both of them. One way to think about this is that I have secp and ed, and I am finding a group structure in this in the obvious way, and then my claim is that these two points, like Tsecp and Ted have the same discrete log. In this larger group, I'm claiming this discrete log of this multipoint is T, T and both the components are the same. I do a ring signature in this cartesian product group, and I'm proving that they are the same in both step, and this is equivalent to the same thing where I was combining hashes.

Satoshi's original vision was apparently sourceforge and the sourceforge mailing list. In 2015, we moved away from sourceforge for the mailing list. We had a hard time picking a host deemed to be neutral at the time. We didn't want to deal with this. At the same time, nobody wants to do any work.

At the time, there was an effort to upgrade to mailman3 because a bigger number is better. Also, some moderators were appointed. Over time it dwindled down to one moderator. Unfortunately, late last year, the Linux Foundation informed us about their intent to discontinue their mailing list hosting services. Mailman2 has been unmaintained upstream for years. It has severe problems from a maintainability perspective, security perspective, the next slide is about that. They tried to throw money at this to fix mailman2 but they failed. Now they want to shut it down, they told me that they had 20,000 other project lists most of which are moved to groups.io. I haven't tried it, but being a commercial service, I think many of us have a kneejerk reaction to proprietary non-open-source things. At least that was the thinking back then.

2019-06-06

<https://twitter.com/kanzure/status/1136591286012698626>

<https://github.com/sipa/bips/blob/bip-schnorr/bip-taproot.mediawiki>

<https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin/>

Signet

<https://twitter.com/kanzure/status/1136980462524608512>

<https://twitter.com/kanzure/status/1136992734953299970>

overview: <https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39>

# Modern Soft Fork Activation

LD: If there is possibly a problem we shouldn’t even get to that first step.

EL: Which is the way it should’ve been in the beginning but I think that it took a while until people realized that that is what the script should be doing. Initially it was thought we could have these scripts that run onchain. This is the way it was done because I don’t think Satoshi thought this completely through. He just wanted to launch something. We have a lot of hindsight now that we didn’t have back then. Now it is obvious that really the blockchain is about authorizing transactions, it is not about processing the conditions of contracts themselves. That can all be done offchain and that can be done very well offchain. In the end the only thing is that the participants need to sign off that it did happen and that’s it. That is all that everyone really cares about. Everyone agreed so what is the big deal? If everyone agrees there is no big issue.

LD: I can’t think of any. There is no reason not to deploy it at least, I can’t think of any reason not to use it either. It does carry over the bias that SegWit toward bigger blocks but that is something that has to be considered independently. There is no reason to tie the features to the block size.

BIP 8: https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

Aaron van Wirdum article on LOT=true or LOT=false: https://bitcoinmagazine.com/articles/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation

Video: https://www.youtube.com/watch?v=oCPrjaw3YVI

Transcript by: Michael Folkson

# Speedy Trial proposal

AvW: Should we begin with Speedy Trial, what is Speedy Trial Sjors?

AvW: That was LOT=true or LOT=false. The debate was on whether or not it should end with forced signaling or not. That’s the LOT=true, LOT=false thing.

AvW: It would end on LOT=false basically.

# Alternative to Bitcoin Core (Bitcoin Core 0.21.0-based Taproot Client)

AvW: Another client was also launched. There is a lot of debate on the name. We are going to call it the LOT=true client.

The solution here is to use covenants in the HTLC outputs. This eliminates signature + verify with commitment creation, and eliminates signature storage of current state. We're basically making an off-chain covenant with 2-of-2 multisig. We can just say, if we actualy have real covenants then we don't them anymore. The goal of the covenants was to force them to wait the CSV delay when they were trying to claim the output. But with this, they can only spend the output if the output that it created in the spending transaction actually has a CSV delay clause. You basically add an independent script for HTLC revocation clause reusing the commitment invalidation technique.

# Multi-party channels

# Taproot

# Scriptless scripts

That's all.

# Q&A

----

# Flag dates and user-activated soft-forks

The problem with bip148 is that the segwit2x collusion agreement came up and it was too late to activate with just bip9. James Hilliard proposed a reduction of the activation threshold to 80% using <a href="https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki">bip91</a>. It was a way to avoid the chain split with the segwit2x collusion agreement, but it did not avoid the chainsplit with the bcash thing which I think it was inevitable at that point. The bcash hard-fork was a separate proposal unrelated to bip91 and bip8.

Near-term soft-forkable changes that people have been looking into include things like: <a href="https://diyhpl.us/wiki/transcripts/blockchain-protocol-analysis-security-engineering/2018/schnorr-signatures-for-bitcoin-challenges-opportunities/">Schnorr signatures</a>, signature aggregation, which is much more efficient than the currently used ECDSA scheme. And MASTs for <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-06-merkleized-abstract-syntax-trees-mast/">merkleized abstract syntax trees</a>, and there are at least two different proposals for this. MAST allows you to compress scripts where there's a single execution pathway that might be taken so you can have this entire tree of potential execution pathways and the proof to authorize a transaction only needs to include one particular leaf of the tree.

# Potential changes requiring hard-forks

stark: There's never a dull moment in bitcoin. There's been discussion in the community about upgrades and block size. How do you think we can most securely upgrade the bitcoin protocol?

stark: We've seen proposals from the community about ways to upgrade bitcoin. How would you do those differently?

# Dust HTLC exposure (Lisa Neigut)

The email Antoine sent to the mailing list this morning. With c-lightning there is a dust limit. When you get a HTLC it has got an amount that it represents, let’s say 1000 sats. If the dust limit is at like 543 which is where c-lightning defaults to, if the amount in the HTLC is above the dust limit then we consider it trimmed which means it doesn’t appear in the commitment transaction and the entire output amount gets added to the fees that you’d pay to a miner if that commitment transaction were to go onchain. There are two problems. In other implementations the dust limit is set by the peer and it is tracked against what the reserve is. They can set that limit really high. You get HTLCs coming in, they could be underneath the dust limit even if your fee rate for the commitment transaction isn’t very high. Basically the idea is if you have a high dust limit, let’s say 5000 sats, every HTLC that you get which is 1000 sats will be automatically be trimmed to dust. If you’ve got a channel with a pretty high dust limit and someone puts a lot of HTLCs on it then all of a sudden your amount of miner fees on that commitment transaction are quite high. If they unilaterally close the channel, the dust limit is used on the signatures that you send to your peer, then all of that amount that was dust now goes to the miner. If the miner was going to pay them back money it is a way that they could extract value. This has been a longstanding problem with Lightning. I gave a [talk](https://www.youtube.com/watch?v=e9o6xepAD9E) on dust stuff at Bitcoin 2019. It is not really new, I think the new part of the attack is that the peer can set the dust limit. c-lightning has a check where the max dust that your peer can set is the channel reserve, like 1 percent of the channel. So c-lightning isn’t as badly affected as some of the other implementations. That’s one side of it. The other side, the recommended fix is that now when you are taking a HTLC and you are saying “This is now dust”, we have a bucket and we add every HTLC amount as dust to this bucket. When the bucket gets full we stop accepting HTLCs that are considered dusty.

<https://medium.com/blockstream/c-lightning-v0-10-2-bitcoin-dust-consensus-rule-33e777d58657>

I have been trying to ignore the whole issue. I knew there was an issue, I was like “Everyone else will handle it” and I have learned my lesson. The spec fix doesn’t work in general. It was messy. When I read what they were actually doing, “No we can’t actually do that”. I proposed a much simpler fix. Unfortunately my timing was terrible, I should have done it a month ago. I apologize for that. I read Lisa’s PR and went back and read what the spec said, “Uh oh”.

# Full RBF in Core

We are already moving towards RBF on Lightning with the dual funded channel proposal. All those transactions that we create are RBFable. I feel like the question you are asking, not explicitly, is the zero conf channel proposal which is currently spec’ed. We didn’t talk about it but full RBF would interact quite poorly with zero conf channels. RBF means that any transaction that gets published to the mempool can then be replaced before it is mined in a block. Zero conf kind of assumes that whatever transaction you publish to the mempool will end up in a block. There is tension there. I don’t think there is an easy answer to that other than maybe zero conf channels aren’t really meant for general consumption. The general idea with zero conf in general is that it is between two semi trusted parties. I don’t think that’s a great answer but I think there is definitely a serious concern there where zero conf channels are concerned.

When I was in Zurich a few weeks ago I spent some time talking to Christian about how to update our accounting stuff. I would really like to get an accounting plugin done soon. I did some rethinking about how we do events, it is an event based system. Coins move around, c-lightning emits an event. I am going to make some changes to how we are keeping track of things. I think the biggest notable change is we will no longer be emitting events about chain fees which kind of sucks. There is a good reason to not do that. Instead the accounting plugin will have to do fee calculations on its own which I think is fine. That is probably going to be the biggest change. Working through that today, figuring out what needs to change. Hopefully the in c-lightning stuff will be quite lightweight and then I can spend a lot of time getting the accounting plugin exactly where I want it. That will be really exciting. I am also going to be in Atlanta, Wednesday through Sunday at the TAB conference. I am giving a [talk](https://www.youtube.com/watch?v=mVihRFrbsbc&t=6470s), appearing on a panel and running some other stuff. I will probably be a little busy this week preparing for the myriad of things someone has signed me up for. If anyone has suggestions about topics to talk about you have 24 hours to submit submissions if there are things on Lightning you want to hear about.

That was brave. I think it is great. I think you are wrong but that is ok.

I think there should be something out to stderror. But also we should probably use a specific exit error code in the case... That would be a lot easier to detect. PRs welcome. It is a simple one but it is the kind of thing that no one thought about. Just document it in the lightningd man page. Pick error codes, as long as nothing else gets that error code it would be quite reliable. I think `1` is our general error code, `0` is fine. `1` is something went wrong, anything up to about `125` is probably a decent error, exit code for hsm decoding issues. As you say it makes perfect sense because it is a common use case. If you ever want to automate it you need to know.

You did actually code it up as well? It was more than just a mailing list post? I didn’t see the branch.

# Fraud-Proofs

Audience member: Does this solution protect you against the DoS attack vector?

Cross talk...

Audience member: Highly asymmetric.

John: That condition is much harder.

John: Let’s take a step back and talk about Satoshi implementing Bitcoin. Satoshi wrote a white paper and then produced a reference implementation of Bitcoin. In that reference implementation there was a dependency on OpenSSL that was used for many things.

# Tainting, CoinJoin, PayJoin, CoinSwap Bitcoin dev mailing list post (Nopara)

….

# Disclosure of a fee blackmail attack (Rene Pickhardt)

Let’s move onto this cousin I would say of attacking the Lightning Network. This is more or less very similar to what we just talked about. Instead of the attacker getting the funds it is a blackmail situation. Nobody can claim the funds but you can negotiate with your counterparty, you get half I get half sort of thing. I think Rene Pickhardt had a good TL;DR here. This attack demonstrates why opening a channel is not an entirely trustless activity. You actually do need to have a little bit of trust with your peer. With this attack the attacker will reliably only be able to force the victim to lose this amount of Bitcoin.

# Pinning: The Good, The Bad, The Ugly (Antoine Riard)

This is related to a lot of this higher level work on fees on Lightning. The game theory of the Lightning Network really relies on how fees interact with things and how quickly we can get things included in the blockchain to enforce these HTLC contracts. This mailing list post is talking about how the mempool works in Bitcoin. A mempool is where we collect transactions before they get included in a block. We usually prioritize them by fee rate so if you have the highest fee you are likely to be included in the next block. If you have a low fee it may be a few days before your transaction is included. We saw this behavior play out in the 2017 rampant market speculation that was going on. As Antoine says here the “Lightning security model relies on the unilateral capability for a channel participant to confirm transactions.” That means I don’t care what my peer thinks in my Lightning channel, I want to go to the chain now and he can’t do anything to stop me. That is a fundamental property that we need in Lightning to make the security model work. “This security model is actually turning back the double-spend problem to a private matter” which I thought was a really interesting insight here. “… making the duty of each channel participant to timely enforce its balance against the competing interest of its counterparties.” Not the entire Bitcoin ecosystem is responsible for enforcing say consensus rules, it is you that is responsible for enforcing the rules of your channel. There is nobody else that can help you modulo maybe watchtowers or something like that. As a byproduct of this from the base level you need to make sure we have effective propagation and timely confirmation of Lightning transactions because it is a cornerstone of the security model of Lightning. This is where it really starts to get interesting. Antoine points out here that “network mempools aren’t guaranteed to be convergent”. If somebody is running a Bitcoin node in Japan, somebody is running one in San Francisco, there is some network latency, one transaction is propagated to you faster on one side of the world. Another conflicting transaction is propagated faster on the other side of the world. You could end up with two different states of the world and then reject the other person’s state because it conflicts with what you see. You think it is invalid because you saw something else first. Order matters when keeping a local mempool. As Antoine says here “If subset X observes Alice commitment transaction and subset Y observes Bob commitment transaction, Alice’s HTLC-timeout spending her commitment won’t propagate beyond the X-Y set boundaries.” They will have two different states of the world. One set of the Bitcoin nodes will think the transaction is invalid, another set will think it is invalid and we won’t come to any sort of convergence on what mempools are. The whole point of a blockchain is to converge on a set of UTXOs over a long period of time. This is why we need confirmations to make sure that history is final onchain. A proposal that Antoine has is being able to unilaterally and dynamically bump the fee rate on any commitment transaction is a property that we need to ensure the Lightning Network’s security model is fully realized. “Assuming mempool congestion levels we have seen in the past months, currently deployed LN peers aren’t secure against scenario 2a and 2b.” One of these scenarios requires work at the base layer.

David Harding wrote this. He puts in concrete terms the different sorts of attacks on Lightning. You can have “preimage denial” which is Mallory can prevent Bob from learning the preimage by giving the preimage settlement transaction a low fee rate that keeps it from getting confirmed quickly. If Bob is only looking for preimages in the blockchain he won’t see Mallory’s transaction while it remains unconfirmed. The key thing with this preimage denial attack is Bob doesn’t have a mempool. He can only see what is in the blockchain. If Mallory, being malicious, gives a transaction a low fee it can look like the payment preimage has been revealed and Bob doesn’t know it. Mallory can steal Bob’s funds here. The second thing David talks about is prior to broadcasting the preimage settlement transaction she can prevent miners and Bitcoin relay nodes from accepting Bob’s later broadcast of the refund settlement transaction because the two transactions conflict which is just what we were talking about. They “both spend the same input (a UTXO created in the commitment transaction). In theory Bob’s refund settlement transaction will pay a higher fee rate and so can replace Mallory’s preimage settlement but in practice Mallory can use various transaction pinning techniques to prevent that replacement from happening.”

There are three proposed solutions. Require a mempool, beg or pay for preimages and settlement transaction anchor outputs. It is interesting stuff. A lot more scrutiny on the Lightning Network security model in the last month so we can build a more resilient network.

# BIP draft: BIP 32 Path Templates (Dmitry Petukhov)

This is similar to a wallet descriptor but it is kind of like a BIP 32 xpub descriptor, what valid BIP 32 paths to use with this xpub. What this lets you do is say if you are developing a wallet and your wallet only uses an account at index 0 with HD purpose 84, 0 and 1 for if it is change or not. In that example 0 to 5000, for the coin index, this makes it a lot easier for other wallets to be compatible with each other. Right now if you import an Electrum wallet into another wallet you will need to rescan and randomly search around to try to find the coins. With this you say exactly where your coins are going to be because it comes from this wallet with this descriptor. On Wasabi there is a lot of pushback on going off the most minimal implementation of BIP 44 where you are just using the purposes, the default account, zero and one for if it is change or not. This allows you to get outside of the box with that stuff and use it in more creative ways without other wallets not being able to find it unless they explicitly look for those random things. You just tell them my coins will be here, you should look here. I think that will be huge for backups and wallet interoperability.

# Time Dilation Attacks on the Lightning Network (Gleb Naumenko, Antoine Riard)

Right now for a Lightning channel if I am broadcasting a revoked state or if I am trying to close a channel and redeem a HTLC you need onchain access. You need to view the chain. We know that since the beginning of Lightning you need to watch the chain. What we didn’t know is eclipse attacks against Lightning nodes are far more worrying because I can announce the block on the real chain but I am doing so with a slowdown in announcements. Accumulating this slowdown the view of the chain by your Lightning node is going to be 20 blocks back. When I know that your view of the blockchain is 20 blocks back I am going to close the channel and the revocation delay is going to be 19 blocks. I am going to withdraw the funds and you are not going to be able to punish me. When your Lightning peer reaches the same height the timelock is going to already be expired. You need to see the chain but you also need to see the chain in a timely manner. Time is super important in Lightning. The cool thing about these attacks is you don’t need to assume hashrate for the attacker. Your counterparty doesn’t need to be a miner.

# Dynamic Commitments: Upgrading Channels Without On-Chain Transactions (Laolu Osuntokun)

Here is our first technical topic. This is to do with upgrading already existing Lightning channels.

# Advances in Bitcoin Contracting: Uniform Policy and Package Relay (Antoine Riard)

This is the P2P Bitcoin development space, this package and relay policy across the Bitcoin P2P network. What this problem is trying to solve is there are certain layer 2 protocols that are built on top of Bitcoin such as Lightning that require transactions to be confirmed in a timely manner. Also sometimes it is three transactions that all spend each other that need to be confirmed at the same time to make sure that you can get your money back specifically with Lightning. As Antoine writes here, “Lightning, the most deployed time-sensitive protocol as of now, relies on the timely confirmations of some of its transactions to enforce its security model.” Lightning boils down to if you cheat me on the Lightning Network I go back down to the Bitcoin blockchain and take your money. The assumption there is that you can actually get a transaction confirmed in the Bitcoin blockchain. If you can’t do that the security model for Lightning crumbles. Antoine also writes here that to be able to do this you sometimes need to adjust the fee rate of a transaction. As we all know blockchains have dynamic fee rates depending on what people are doing on the network. It could be 1 satoshis per byte and other times it could be 130 satoshis per byte. Or what we saw with this Clark Moody dashboard, one person may think it is 130 satoshis per byte while another person is like “I have a better view of the network and this person doesn’t know what they are talking about. It is really 10 satoshis per byte.” You can have these disagreements on these Layer 2 protocols too. It is really important that you have an accurate view of what it takes to enforce your Layer 2 transactions and get them confirmed in the network. The idea that is being tossed around to do this is this package relay policy. Antoine did a really good job of laying out exactly what you need here. You need to be able to propagate a transaction across the network so that everyone can see the transaction in a timely manner. Each node has different rules for transactions that they allow into the mempool. The mempool is the staging area where nodes hold transactions before they are mined in a block. Depending on your node settings, you could be running a node on a Raspberry Pi or one of these high end servers with like 64GB of RAM. Depending on what kind of hardware you are running you obviously have limitations on how big your mempool can be. On a Raspberry Pi maybe your mempool is limited to 500MB. On these high end servers you could have 30GB of transactions or something like that. Depending upon which node you are operating your view of the network is different. In terms of Layer 2 protocols you don’t want that because you want everybody to have the same view of the network so they can confirm your transactions when you need them to be confirmed.

There's lots of really cool things going on. And often in the bitcoin space people are looking for the bitcoin developers to set a roadmap for what's going to happen. But the bitcoin project is an open collaboration, and it's hard to do anything that's like a roadmap.

It's the same kind of thing that also applies to bitcoin. What's going to happen in bitcoin development? The real answer to that is another question: what are you going to make happen in bitcoin development? Every person involved has a stake in making it better and contributing. Nobody can really tell you what's going to happen for sure. But I can certainly talk about what I know people are working on and what I know other people are working on, which might seem like a great magic trick of prediction but it's really not I promise.

# More improvements

Another thing that people are working on is <a href="http://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf">branch-and-bound coin selection</a> to produce changeless outputs much of the time. So this is <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/coin-selection/">Murch's design</a> which Andrew Chow has been working on implementing. There's <a href="https://github.com/bitcoin/bitcoin/pull/10637">a pull request</a> barely missed going into v0.15 but the end result of this will be transactions less expensive for users and making the network more efficient because it's creating change outputs much less often.

# Rolling UTXO set hashes

<div id="signature-aggregation" />

# Signature aggregation

Other things going on with the network and consensus... There's <a href="https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki">bip150</a> and <a href="https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki">bip151</a> (see the <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/bip151-peer-encryption/">bip151 talk</a>) for encrypted and optionally authenticated p2p. I think the bips are half-way done. Jonas Schnelli will be talking about these in more detail next week. We've been waiting on network refactors before implementing this into Bitcoin Core. So this should be work that comes through pretty quickly.

Q: Is the dandelion approach going to effect how fast your transactions might get into a block? If I'm not rushed...?

There's been ongoing work on improved block fetch robustness. So right now the way that fetching works is that assuming you're not using compact blocks high-bandwidth opportunistic send where peers send blocks even without you asking for it, you will only ask for blocks from a single peer at a time. So if I say give me a block, and he falls asleep and doesn't send it, I will wait for a long multi-minute timeout before I try to get the block from someone else. So there's some work ongoing to have the software try to fetch a block from multiple peers at the same time, and occasionally waste time.

# Further further....

Q: There's a few different proposals nad trying to solve the same thing, like weak blocks, thin blocks, invertible bloom filters, is there anything in that realm on the horizon, what do you think is the most probable development there?

Q: Is rolling utxo hash a segwit precondition?

Q: Hey uh... so it sounds like you, in November whenever s2x gets implemented, and it gets more work than bitcoin, I mean it sounds like you consider it an altcoin it's like UASF territory at what point is bitcoin is bitcoin and what would y'all do with sha256 algorithm if s2x gets more work on it?

Q: So sha256 is not a defining characteristic of bitcoin?

# What about xthin?

# What about "Xpedied"?

Politics are a big hurdle-- some people don't want bitcoin to improve on the privacy aspects, and some people don't want bitcoin to improve at all. But I think that privacy and the existence of CT and sidechains and so on will remove these arguments. If bitcoin should use CT, and competing systems use it, I don't think it will take forever.

So the tech is still maturing for CT. If the reason for it not be deploying right now is 15x, well is 10x enough? With improvements we can get this down to lower amounts. As the technology improves, we could make this story better. I am happy to help with other people experimenting with this. I think it's premature to do CT on litecoin today, Charlie, but I would like to see this get more use of course.

# Is Taproot development moving too fast or too slow?

The bulk of the Taproot proposal, other than Taproot itself and specific encoding details, is significantly older too. (Enough that earlier versions of our proposals have been copied and activated in other cryptocurrencies already)

Taproot's changes to bitcoin's consensus code are under 520 lines of difference, about 1/4th that of Segwit's. Unlike Segwit, Taproot requires no P2P changes or changes to mining software, nor do we have to have a whole new address type for it. It is also significantly [de-risked](https://twitter.com/theinstagibbs/status/1285018236719976448) by the script version extension mechanisms added by Segwit. It has also undergone significantly more review than P2SH did, which is the most similar analogous prior change and which didn't enjoy the benefits of Segwit.

Taproot has also been exceptionally widely discussed by the wider bitcoin community for a couple years now. Its application is narrow, users who don't care to use it are ultimately unaffected by it (it should decrease resource consumption by nodes, rather than increase it) and no one is forced to use it for their own coins. It also introduces new tools to make other future improvements simpler, safer (particularly Taproot leaf versions), and more private... so there is a good reason that other future improvements are waiting on Tapoot.

Aaron: So you guys built something. First tell me are you a company? Is this a startup? What is the story here?

Aaron: I’m not sure what the best order is to tackle this. Why didn’t they just use Bryan’s vault design?

Aaron: You have coded this up? Is it ready to be used? What is the status of it?

Aaron: You have mentioned this trading desk. What are other good examples of companies that could use it?

Trezor blog post on the vulnerability: https://blog.trezor.io/latest-firmware-updates-correct-possible-segwit-transaction-vulnerability-266df0d2860

# The vulnerability

# Atomic multi-path payments

Now we're going to move on to one new technology called atomic multi-path payments (amps). The problem is that you need a path on the network between multiple nodes on the graph. The problem is that if Alice wants to send 8 BTC she has to-- these numbers are the capacities in the direction towards Felix. There's a capacity in both directions. If Alice wants to pay Felix she wants to send 8 BTC but she can't because each path on its own doesn't have enough capacity. And Felix at a time can only receive up to 10 BTC because he has that inbound liquidity, but he's unable to because of the single path constraint. This is solved by atomic multi-path payments.

# Splicing overview

Splicing is another cool technology. I think roasbeef came up with the scheme I'm going to present today. There's a lot of different ways to do this. We're still in the research phase. I am just going to present an example that is sort of familiar and easy to graph.

HTLC output scripts are a little more involved but they have script templates too and follow the same general format. There's SIGHASH\_ALL which is one of the sighash flags used in bitcoin required for this... the state space can manifest on chain because of thse 2-state layers of HTLC. Using SIGHASH\_SINGLE it's more liberal than SIGHASH\_ALL and allows us to get this down to a linear amount of space required for the signatures.

# Watchtower upgrade proposals

# New developments

Doing <a href="http://diyhpl.us/~bryan/papers2/bitcoin/Scriptless%20scripts%20with%20ECDSA%20-%202018-04-26.pdf">scriptless scripts with ECDSA</a> would be interesting today. Monero maybe-- doesn't have refund support. None of this works unless you have ECDSA. It turns out there was a paper dropped on lightning-dev about this. There's some groups working on implementing this multi-party ECDSA protocol which is exciting. This could be happening today. People could be doing it today, there's no evidence on the blockchain. You have no idea how many people were involved or what kind of smart contract they were involved. And if you are working for a Chainalysis company then you are lying to yourself and others.

# Innovation on upgrade mechanisms

# Prospect of a community split and an altcoin

# Why Lightning?

# rust-lightning

# To Infinity and Beyond

# Q & A

# Selling (Schnorr) Signatures

# Pay for Decommitment (Pay for Nonce)

A - I think the modularity of the protocol and the modularity of the implementations pretty much go hand in hand. If the specification has very nice modular boundaries where you have separation of concerns, one thing manages updates of state and one thing manages how we communicate with the blockchain and one thing manages how we do multihop security. That automatically leads to a structure which is very modular. The issue that we have currently have is that the Lightning penalty mechanism namely the fact that whatever output we create in our state must be penalizable makes it so that this update mechanism leaks into the rest of the protocol stack. I showed before how we punish the commitment transaction if I were ever to publish an old commitment. But if we had a HTLC attached to that, this HTLC too would have to have the facility for me to punish you if you published this old state with this HTLC that had been resolved correctly or incorrectly or timed out. It is really hard in the penalty mechanism to have a clear cut separation between the update mechanism and the multihop mechanism and whatever else we build on top of the update mechanism. It leaks into each other. That is something that I really like about eltoo. We have this clear separation of this is the update mechanism and this is the multihop mechanism and there is no interference between the two of them. I think by clearing up the protocol stack we will end up with more modular implementations. Of course at c-lightning we try to expose as much as possible from the internals to plugins so that plugins are first class citizens in the Lightning nodes themselves. They have the same power as most of our pre-shipped tools have. One little known fact is that the pay command which is used to pay a BOLT11 invoice is also implemented as a plugin. The plugin takes care of decoding the invoice of initiating a payment, retrying if a payment fails, splitting a payment if it is too large or adding a shadow route or adding fuzzing or all of this. It is all implemented in a plugin and the bare bones implementation of c-lighting is very light. It doesn’t come with a lot of bells and whistles but we make it so that you have the power of customizing it and so on. There we do try to keep a modular aspect to c-lightning despite the protocol not being a perfectly modular system itself.

A - Upfront payments is a proposal that came up when we first started probing the network. Probing involves sending a payment that can never terminate correctly. By looking at the error code we receive back we learn about the network. It is for free because the payments never actually terminate. That brought up the question of aren’t we using somebody else’s resources by creating HTLCs with their funds as well but not paying them for it? The idea came up of having upfront payments which means that if I try to route a payment I will definitely leave a fee even if that payment fails. That is neat but the balance between working and not working is hard to get right. The main issue is that if we pay upfront for them receiving a payment and not forwarding a payment then they may be happy to take the upfront fee and just fail without any stake in the system. If I were to receive an incoming HTLC from Jeff and I need to forward it to you Michael and Jeff is paying me 10 millisatoshis for the privilege of talking to me I might not actually take my half a Bitcoin and lock it up in a HTLC to you. I might be happy taking those 10 millisatoshis and say “I’m ok with this. You try another route.” It is an issue of incentivizing good behavior versus incentivizing abusing the system to maximize your outcome. A mix of upfront payments and fees contingent on the success of the actual payment is probably the right way. We need to discuss a bit more and people’s time is tight when it comes to these proposals. There has been too much movement I guess.

# Aggregation schemes - 2

Q - The per transaction aggregation would mean there is just one transaction in a block?

Video: https://www.youtube.com/watch?v=0lGO5I74qJM

Draft BIP: https://github.com/TheBlueMatt/bips/blob/betterhash/bip-XXXX.mediawiki

Q - Is it public?

Vendor messages, there’s a general trend right now. If you run a mining farm, monitoring and management is actually a pain in the ass. There is one off the shelf solution that I am aware of. They charge you a certain number of dollars per device. It is Windows only, it is not a remote management thing, you have to be there and it is really bad. Most farms end up rolling their own management and monitoring software which is terrible because most of them are people who have cheap power, they are not necessarily technical people who know what they are doing. We want some extensibility there but I am also not going to bake in all the “Please tell me your current temperature” kind of messages into the spec. Instead there is an explicit extensibility thing where you can say “Hi. This is a vendor message. Here is the type of message. Ignore it if you don’t know what that means. Do something with it if you do.” That is all there. That is actually really nice for pools hopefully and for clients. I don’t know why you’d want this but someone asked me to add this so I did. I wrote up a little blurb and how you can use the vendor messages to make the header only, final Work protocol go over UDP because someone told me that they wanted to set up their farm to take the data from broadcast UDP, you don’t have to have individual connections per device and shove it blindly into the ASIC itself without an ASIC controller whatsoever. I don’t know why you’d want to do that but if you do and you are crazy this is explicitly supported. There is a write up of how you might imagine doing such a completely insane thing.

Q - Could you not do it in a trustless way? That would be cool. Somehow the shares already open a Lightning channel or somehow push things inside a channel?

Q - It could be some referential thing, maybe it is Lightning-esque where whatever you are doing in the Lightning channel points back to the hash of the block that you are doing it in?

A - Chris, do you want to explain P2Pool?

Its biggest problem was it was bad UX. It reported a higher stale rate because it had this low inter block time so you had naturally high stale rates. But what mattered for the payouts, for a centralized pool if you have a stale rate you miss that many payouts, in P2Pool if you have a stale rate you can still get payouts for stale shares, the only thing that matters is your stale rate in comparison to other clients. And so you have a lot of miners who were running P2Pool and it said “Hey you have a 2 percent stale rate” and they were like “F\*\*\* this. My centralized pool says I have 0.1 percent stale rate. I am not going to use P2Pool.” And so P2Pool died for no reason because it had bad UX.

A - The core developer in the back points out that it would be useful if you could have a Lightning HTLC where the individual public keys were instead complicated policies. That might be multiple public keys or a CHECKMULTISIG or something and that’s true. If you used Miniscript with Lightning HTLCs then you could have two parties open a channel where one person proposes a HTLC that isn’t actually the standard HTLC template. It is a HTLC template where the keys are replaced by more interesting policies and then your counterparty would be able to verify that. That’s true. That would be a benefit of using Miniscript with Lightning. There is a trade-off between having that ability and having to add special purpose Lightning things into Miniscript that would complicate the system. Maybe we made the wrong choice on that trade-off and maybe we want to extend Miniscript.

Q - I think you can use scriptless scripts to express everything you want on top of Lightning.

One thing that I also just realized is that the sender can do a double spending attack because he makes the first signed transaction and then he receives the pre-signed or partially signed transaction from the receiver. So he knows the fee rate. He can simply not sign the second transaction, the payjoin transaction and double spend the original transaction paying back to himself with a slightly higher fee rate. If he is the one to broadcast transaction first the original transaction may not even be broadcast because full nodes will think it is a double spend if RBF is not activated. That might be an issue to.

# Payjoin in BTCPay Server

BM: Yes. This starts to get into a lot of design as to how do you organize these transactions. What Bryan is discussing is what we call a push-to-recovery-wallet transaction. The thief has gotten in. I have to do something and I am going to push this to another wallet. Now I have three sets of keys. I have the spending keys that I want to use, I have my emergency back out keys and then if I have to use those emergency back out keys I have to somewhere to send those funds that the thief wouldn’t have access to. These vault designs end up getting rather complicated rather fast. I am now talking about three different wallets, each of which in principle should be multisig. If I do 2-of-3 I am now talking about 3 devices. In addition, when this happens, when a thief gets in and tries to steal funds I want to push this transaction. Who does that and how? This implies a set of watchtowers similar to Lightning watchtowers that look for this event and are tasked with broadcasting a transaction which will send it to my super, super backup wallet.

MF: There are different designs here. I am trying to logically get it in my mind. Are there certain frameworks that we can hang the different designs on? We will get onto your mailing list post in a minute Bryan. Kevin has got a different design, Bob seemed to be talking about an earlier design. How do I structure this inside of my head in terms of the different options? Are they are all going to be personalized for specific situations?

BB: Definitely send that to Christopher Allen. He also has an air gapped signing Bitcoin wallet based off of a stripped down iPod touch with a camera and a screen for QR codes. That is on Blockchain Commons GitHub.

BB: There is good news actually. There were actually three. There were two on the first day. While the first one was somewhat interesting it is actually wrong and you should focus on the second one that occurred on that same day which was the one that quickly said “Aaron van Wirdum pointed out that this insecure and the adversary can just wait for you to broadcast an unlocking transaction and then steal your funds.” I was like “Yes that’s true.” The solution is the sharding which I talked about earlier today. Basically the idea is that if someone is going to steal your money you want them to steal less than 100 percent of your money. You can achieve something like that with vaults.

# Mempool transaction pinning problems

BM: I think Jeremy is probably the best to respond to that as he is actively working on this.

BB: I will probably hand this over to Bob or Jeremy about watchtowers. It is a huge problem. The prototype I put together did not include a watchtower even though it is absolutely necessary. It is really interesting. One comment I made to Bob is that vaults have revealed things that we should be doing with normal Bitcoin wallets that we just don’t do. Everyone should be watching their coins onchain at all times but most people don’t do that. In vaults it becomes absolutely necessary but is that a property of vaults or is that actually a normal everyday property of how to use Bitcoin that we have mostly been ignoring. I don’t know.

JR: I think part of the issue is that we are trying to solve too many problems at once. The reality is we don’t even have a good watchtower that I am operating myself and I fully trust. That should be the first step. We don’t even have the code to run your own server for these things. That has to be where you start. I agree longer term outsourcing makes sense but for sophisticated contracts we need to have at least something that does this functionality that you can run yourself. Then we can figure out these higher order constraints. I think we are putting the cart before the horse on completely functional watchtowers that are bonded. That stuff can come later.

# Clawback

Bob McElrath: Two little points. One is that you discussed having the ability to do a timelock from the time of signing. It is cryptographically possible using timelock puzzles or verifiable delay functions but I think this is very far from anything people would want to use it right now. For those that are interested in crypto something to keep an eye on. Secondly somebody asks in the chat how do you prove the private key was deleted? Generally you can’t. An alternative is to use ECDSA key recovery but that cannot be used with Bitcoin today because the txid commits to the pubkey which you don’t know at the time you do the key recovery.

The first challenge we encountered is a very common one which we have been discussing a lot for the Lightning Network. How to get pre-signed transactions confirmed in a timely manner for multiparty contracts. Our security models on our Revault transactions to be enforceable at any time. We need to find a way for transactions to pay the right fees according the fee market when we want to broadcast them. We could use something like the [update_fee](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee) message currently used in the Lightning Network protocol which asks our peer to sign a new commitment transaction with us as the current fee rate increases or a new one when the fee rate decreases. We can’t trust the other parties to sign the transaction. Firstly, because they might be part of the attack. With vault we are talking bid only so they have a strong incentive to take the vault money and act badly and refuse to sign a Revault transaction. Secondly even if they are honest it would just require an attacker to compromise one party to prevent a Revault transaction being executed. Finally they may not be able to sign it in the first place. They may have their HSM available. In addition it would require them to draw their HSM each time there is a fee rate bump. This is just not practical. We are left with either using anchor outputs, what has been planned for the Lightning Network or letting each party attach inputs to the transactions aka bring your own fees. We went for the second one.

# Optimization / standardness fun

Pastebin of the resources discussed: https://pastebin.com/uyktht33

The conversation has been anonymized by default to protect the identities of the participants. Those who have given permission for their comments to be attributed are attributed. If you were a participant and would like your comments to be attributed please get in touch.

# Design for a CoinSwap implementation (Chris Belcher, 2020)

MF: This is Chris’ mailing list post from May of this year. There’s also the [gist](https://gist.github.com/chris-belcher/9144bd57a91c194e332fb5ca371d0964) with more details on the design. How does this proposal differs from your work Adam in 2017?

RS: I like the argument of Coinjoining first and then using the result in a CoinSwap. That seems pretty good in the sense that you do have some anonymity already. Whoever receives that UTXO is not going to receive a fully tainted UTXO, it is already mixed with other Coinjoins.

# Succinct Atomic Swaps

RO: I wasn’t really involved in the construction of those proposals so I am not a good person to discuss them.

PW: One comment I wanted to make is I think what Russell and I talked about originally with the term MAST isn’t exactly what it is referred to now. Correct me if I’m wrong Russell but I think the name MAST better applies to the Simplicity style where you have an actual abstract syntax tree where every node is a Merklization of its subtree as opposed to BIP 114, 116, BIP-Taproot, which is just a Merkle tree of conditions and the scripts are all at the bottom. Does that distinction make sense? In BIP 340 we don’t use the term MAST except as a reference to the name because what it is doing shouldn’t be called MAST. There is no abstract syntax tree.

# Greg Maxwell Bitcoin dev mailing list post on Taproot (2018)

MF: One of the key points here once we have discussed that conceptual type stuff is that pre-Taproot we thought it was going to be an inefficiency to try to have this construction. The key breakthrough with Taproot is that it avoids any larger scripts going onchain and really doesn’t have any downsides. Greg says “You make use cases as indistinguishable as possible from the most common and boring payments.” No privacy downsides, in fact privacy is better and also efficiency. We are getting the best of both worlds on a number of different axes.

# AJ Towns on formalizing the Taproot proposal (December 2018)

MF: The next item on the reading list was AJ Town’s first attempt to formalize this in a mailing list post in 2018. How much work did it take to go from that idea to formalizing it into a BIP?

# John Newbery on reducing size of Taproot output by 1 vbyte (May 2019)

MF: One of the first major changes was this post from John (Newbery) on reducing the size of the pubkey. The consideration always is we don’t want anyone to lose out. Whatever use case they have, whether they have a small script or a really large script, we don’t want them to be any worse off than before because otherwise you then have this problem of some people losing out. It seems like a fiendish problem to make sure that at least everyone’s use case is not hurt even if it is a very small byte difference. I suppose that is what is hanging over this discussion and John’s post here.

# Pieter Wuille mailing list post on Taproot updates (no P2SH wrapped Taproot, tagged hashes, increased depth of Merkle tree, October 2019)

MF: The next item on the reading list, you gave an update Pieter in October 2019 on the mailing list. The key items here were no P2SH wrapped Taproot. Perhaps you could talk about why people wanted P2SH wrapped Taproot. I suspect it is exactly the same reason why people wanted P2SH wrapped SegWit. There is also tagged hashes and increased depth of Merkle tree.

MF: There hasn’t been much criticism and there doesn’t appear to have been much opposition to Taproot itself. We won’t talk about [quantum resistance](https://bitcoin.stackexchange.com/questions/91049/why-does-hashing-public-keys-not-actually-provide-any-quantum-resistance) because it has already discussed a thousand times. There was this post on the mailing list post with potential criticisms of Taproot in February that is covered by the Optech guys. Was there any valid criticism in this? Any highlights from this post? It didn’t seem as if the criticism was grounded in too much concern or reality.

# Andrew Kozlik on committing to all scriptPubKeys in the signature message (April 2020)

MF: This is what Russell was alluding to. This is Andrew Kozlik’s post on committing to all scriptPubKeys in the signature message. Why is it important to commit to scriptPubKeys in the signature message?

Greg Maxwell on Graftroot (Feb 2018)

AJ Towns on G’root (July 2018)

Pieter Wuille on G’root (October 2018)

AJ Towns on cross input signature aggregation (March 2018)

AJ Towns on SIGHASH_ANYPREVOUT (May 2019)

MF: The next links are things that didn’t make it in. There is Graftroot, G’root, cross input signature aggregation, ANYPREVOUT/NOINPUT. As the authors of Taproot what thought do you have to put in in terms of making sure that we are in the best position to add these later?

# testnet4

MF: Peter Todd back in 2018 when they were discussing a reset of testnet put forward the view that testnet should be a large blockchain. That motivation that AJ said earlier about wanting to reset the testnet just because it gets too big, it takes too long to sync, IBD takes too long. Peter is saying in this mailing list post that you actually want it to be similar size to mainnet if not bigger. Let’s say the block size, block weight discussion starts up again in 5 years, you want to know what is possible before there starts to be performance issues across the network. Perhaps you do want testnet to be really big for those use cases, to experiment with a massive chain prior to thinking about whether we should blocks sizes smaller or bigger or whatever.

# Signet on bitcoin-dev mailing list (March 2019)

MF: This is the announcement on the dev mailing list. Let’s have this discussion then on having one Signet which everyone uses or having multiple Signets. The problem that I foresee if there is just one is that then you get into the same issue that you do on mainnet where it is like “I want my change on Signet.” Jeremy Rubin comes and says “I want CHECKTEMPLATEVERIFY” and you go “Right fine.” Then someone else comes along with a change that no one is particularly interested or everyone thinks is a bad idea. “I want this on Signet.” Then you are in the same situation that we are on mainnet where it is very hard to get new features on the Signet. It needs at least with you and AJ as the signers it needs you or AJ to sign off that change is worthy of experimentation on Signet. Would you agree that is one of the downsides to having one Signet that everybody uses?

KA: There are several issues that you have to tackle when you are trying to test out new features with the Bitcoin setup. Once you turn it on if you find a bug do we reset the chain now? I think AJ has been working on various [ideas](https://bitcoin.stackexchange.com/questions/98642/can-we-experiment-on-signet-with-multiple-proposed-soft-forks-whilst-maintaining) to make it so that you can turn it on but then you say “Oops we didn’t actually turn it on. That was fake. Ignore that stuff.” Then you turn it on again later. So you can test out different stages of a feature even early stages. You can turn it on, see what happens and then selectively turn them off after you realize things were broken.

KA: I don’t think so.

KA: I have pull requests to make it possible to do Lightning stuff.

“All signets use the same hardcoded genesis block (block 0) but independent signets can be differentiated by their network magic (message start bytes). In the updated protocol, the message start bytes are the first four bytes of a hash digest of the network’s challenge script (the script used to determine whether a block has a valid signature). The change was motivated by a desire to simplify the development of applications that want to use multiple signets but which need to call libraries that hardcode the genesis block for the networks they support.” Bitcoin Optech

MF: I did listen to your podcast Andrew with Stephan Livera that came out in the last couple of days. You said a lot of people have been trying with their wallets to send Bitcoin to mainnet Taproot addresses. Some of them failed, some of them succeeded and some of them just locked up their funds so they couldn’t even spend them with an anyone-can-spend. Do you know what happened there?

MF: They sent them to bech32 Taproot addresses rather than bech32m Taproot addresses and the bech32 Taproot addresses can’t be spent. Is that why they are locked up forever?

# The descriptor BIPs

AC: There is a [PR](https://github.com/bitcoin/bips/pull/1143) open. Feel free to assign 7 numbers for me, thanks.

https://btctranscripts.com/advancing-bitcoin/2020/2020-02-06-antoine-riard-taproot-lightning/

https://github.com/ElementsProject/scriptless-scripts/blob/master/md/multi-hop-locks.md

CS: I was talking with some Lightning folks this weekend and talking about what’s on the roadmap for various Lightning companies. My argument to them is we need more adoption on the Lightning Network, I think everybody agrees with this, and number is going up currently and that is great. One of the reasons that number go up could be attributed to lnd adding new features like [keysend](https://bitcoinops.org/en/topics/spontaneous-payments/). I have issues with keysend but I don’t think it can be argued that there is a lot more applications that are enabled by this. I think we need to pitch them the same way as PTLCs. We have written a whole [archive](https://suredbits.com/category/payment-points/) about things you can do with PTLCs, it is going to enhance the expressiveness of the Lightning Network which is going to make number go up even more on the Lightning Network. We need to pitch them on this new feature set, your last features didn’t really go through the consensus process for Lightning to integrate. You’ve got some interesting apps out there for that. The same thing can happen in PTLC world. Unfortunately going back to what we already hashed over was it is much more invasive to do PTLC stuff around the core HTLC state machine logic that already exists.

MF: I get the sense roasbeef is more on the disruptive side rather than the conservative side.

FD: It is custodial in the beginning, nobody even knows yet if the wallet is going to be onchain or a Lightning wallet, the wallet coming up on September 7th. We are hearing that it will have an integration with Lightning from the get go. Whether it is a custodial or a non-custodial wallet I think it doesn’t really matter because ultimately if the wallet can allow for people to withdraw onchain or through Lightning then anyone can use any wallet out here. That is what the government is trying to push forward, for anybody to use any wallet that is available. There is Bitcoin Beach, Wallet of Satoshi, some people are using Muun and Strike of course. I think over time as people get more comfortable and they understand how to use wallets they will use whatever wallet works for them. I think there will be increased level of usage. I don’t want to be a prophet and say something that might not happen but what I can see here there is going to be an explosion of usage.

FD: Not at all.

host: So if it took 7 years to write, it could take 7+ years to read. The book said that, right. Lots of mathematicians had difficulty grasping it because it was so arcane and deep and so involved, so that's interesting, it's not surprising that you go down one rabbit hole and not everyone can necessarily follow you without that same amount of time to go down that rabbit hole. Interesting response. Yeah it's something, I got to AP Calculus and that's about it. The higher-order math and cryptography has always fascinated me. So I was really curious to hear what you thought about that, so it's an interesting response, thank you. Great discussion on mimblewimble. We have a minute left. It's been a pleasure to have you guys on. Thank you.

and <https://www.reddit.com/r/Bitcoin/comments/4xge51/mimblewimble_how_a_strippeddown_version_of/>

<http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2016/fraud-proofs-petertodd/>

<https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log>

<http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-06-taproot-graftroot-etc/>

You start by making a public key, the same way you do to create your addresses. Say you have your script S. What you do is you compute the key C and you send the taproot. I skipped the elliptic curve operations, but if you're familiar with any of this stuff then this is how you turn a private key into a public key, you multiply by G. You can add public keys together, it's quick and really simple to do. And if you add the public keys, then you can sign with the sum of the private keys, which is a really cool detail. What you do is say you have a regular key pair, and you also have this script and you perform this taproot equation. You hash the script and the public key together, you use that as a private key, turn that into a public key, and add that to my existing public key. This allows you to have both a script and a key squished into one thing. C is essentially a public key but it also has a script in it. When you want to spend from it, you have the option to use the key part or the script part. If you want to treat it as P2PKH, where you're a person signing off with this, then you know your private key will just be your regular private key plus this hash that you computed which you know. So you sign as if there were no scripts and nobody will be able to detect that there was a script -it looks like a regular signature. But if you want to reveal the script, you can do so, and then people can verify that it is still valid, and then they can execute the script. It's a way of merging p2pkh and p2sh into one.

# Graftroot

<http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-06-taproot-graftroot-etc/>

# Tradeoffs

# Political Things

# Positive

# Maybe

Thinking about the fee market. From a user experience standpoint, fees are very difficult to reason and predict by design, that's just how the system works. Fees are disconnected by transaction value, because it's size-based. You might have a low-value transaction that is big in terms of bytes, so you are paying a high fee on a low-value transaction. You might have a super-large value transaction that has only one small UTXO, so the fee is tiny.

The fee market status, the changes, the economics, market reaction, all plays into the block size as well. The fee market exists today in a narrow band based on simplistic wallet software fee behavior. If you think through some scenarios about block size changes, you think if you have full blocks and then we change the block size, that might reboot the fee market and then introduce chaos into the user experience. If you don't have full blocks, then you might not have that hurdle. A large block size step might reboot the fee market.

<https://github.com/ElementsProject/lightning>

irc.freenode.net #lightning-dev

----

# References

paper <http://murch.one/wp-content/uploads/2016/09/CoinSelection.pdf>

mimblewimble podcast <http://diyhpl.us/wiki/transcripts/mimblewimble-podcast/>

and <https://www.reddit.com/r/Bitcoin/comments/4xge51/mimblewimble_how_a_strippeddown_version_of/>

onion routing protocol for lightning <https://github.com/cdecker/lightning-rfc/blob/master/bolts/onion-protocol.md>

Or Sattath (The Hebrew University)

<https://www.reddit.com/r/Bitcoin/comments/72qi2r/redesigning_bitcoins_fee_market_a_new_paper_by/>

But bitcoin isn't mimblewimble, and people use scripts like timelocks and lightning channels. petertodd has some weird things like coins out there that you can get if you collide sha1 or sha256 or basically any of the hash functions that bitcoin supports. You can implement hash collision bounties and the blockchain enforces it.

Q: Can you do timelocks iwth adaptor signatures?

A: You'd have to diagram that out for me. There's a few ways to do this, some that I know, but yours isn't one of them.

For timelocks, it appears that you need script support. That's my current belief at this time of day.

<https://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/statechains/>

<https://www.coindesk.com/the-vault-is-back-bitcoin-coder-to-revive-plan-to-shield-wallets-from-theft>

* <https://diyhpl.us/wiki/transcripts/realworldcrypto/2018/mimblewimble-and-scriptless-scripts/>

* zero-knowledge contingent payments: <https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/>

* Equivalent secret values across curves: <https://0bin.net/paste/Q5perGCU3+QMVnhz#fNpHXjX0me3Wa-UBItl4hTeK7wjBkl8JlFAmsbTlZVA>

# References

* <https://github.com/Blockstream/contracthashtool>

<https://twitter.com/kanzure/status/1048483254087573504>

# Introduction

# Intro

# Why?

# TXO bitfields

So there's been discussions of maybe using UTXO bit fields, I had a good discussion with petertodd about his alternative approach to this whole thing, wherein I said this weird comment because he likes UTXO bit fields, I said the thing that might be useful there is that you can compress things down a lot. And it turns out that this really helps a lot. I had this idea for a UTXO bit field. UTXO is all the unspent transaction outputs. It includes all unspents. The idea with a UTXO bit field is that you have a wallet, a proof of position and its private key. As things are added to blocks, each one has a position, and no matter how many things are added later, it is already in the same position always. So to make the validation easier for the full node, the wallet will give the proof of position which it remembers for the relevant inputs that it's using, and bundles that with the transaction to send it to the full node, who then a miner puts it into a block. The proofs of positions will be substantially larger than the transactions, so that's a tradeoff.

The downside is that these proofs of positions are much bigger than the transactions. And this is based on the TXO set size, rather than the UTXO set size which is probably trending towards some constant. In the long term it might grow iwthout bound. There is a pretty straightforward way of fixing that, which is making a fancier bit field. When it's sparse, at the expense of it being much more interesting to implement, you can retain the exact same semantics while making the physical size that the bitfield usig is equal to the number of bits that are set to 1 times the log of the total number of bits, which isn't scary in the slightest. So this is still going to be quite small. To get this working, you'd have to go through an exercise about making a good merkle set, and someone is going to have to think about it, experiment with it and figure out what implementation is going to perform well. Whereas a straightforward bit field is just trivial.

Q: The proof of position... is that position data immutable?

# Other links

# Signature system improvements

I will also be talking about <a href="https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/">signature aggregation</a> (or <a href="https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/">here</a>), in particular aggregation across multiple inputs in a transaction. There's really two separate things, I believe. There's the signature system and then the integration and we should talk about them separately. Lots of the interest in the media on this topic are easily conflated between the two issues.

# Schnorr signature BIP draft

# Schnorr signature properties

# Cross-input signature aggregation

Another complication is soft-fork compatibility. The complication is that when you want different versions of software to validate the same set of inputs, and there is only a single signature, you must make sure that this signature and they both understand that this signature is about the same set of keys. If they disagree about the set of keys or about who has to sign, then that would be bad. Any sort of new feature that gets added to the scripting language that changes the set of signers, is inherently incompatible with aggregation. This is solvable, but it's something to take into account, and it interacts with many things.

# SIGHASH\_NOINPUT

# eltoo

# Taproot

Taproot gives the ability to say-- it's based on the idea that we can use a construction called pay-to-contract which was originally invented by Timo Hanke in 2013 I think, to tweak a public key with a script using the equation there on the screen.

Delegation means we're now going to permit spending, by saying "I have a signature with this taproot key (the key that represents everyone involved)", revealing a script, revealing a signature with a key on that script, and the inputs to it. There's a group of participants that represent the "everyone agrees" case, and they have the ability to delegate spending to other scripts and other particpants.

This may mean difficulty with backups for example, because your money is lost if you lose the signature for example.

# Half-aggregation

# Taproot and graftroot in practice

Over the past few weeks, Bitcoin Optech has organized structured <a href="https://github.com/ajtowns/taproot-review">taproot review sessions</a> (<a href="https://www.coindesk.com/an-army-of-bitcoin-devs-is-battle-testing-upgrades-to-privacy-and-scaling">news</a>) (and <a href="https://bitcoinops.org/workshops/#taproot-workshop">workshops</a> and <a href="https://diyhpl.us/wiki/transcripts/bitcoinops/schnorr-taproot-workshop-2019/notes/">workshop transcript</a> and <a href="https://github.com/bitcoinops/taproot-workshop">here</a>) which has brought in attention and lots of comments from lots of people which have been very useful.

I always make <a href="https://prezi.com/view/AlXd19INd3isgt3SvW8g/">my slides</a> at the very last minute. These people have not seen my slides. If there's anything wrong on them, that's on me.

Okay, so what will this talk be about? I wanted to talk about the actual BIPs and the actual changes that we're proposing to make to bitcoin to bring taproot, Schnorr signatures, and merkle trees, and a whole bunch of other things. I am mostly not going to talk about taproot as an abstract concept. <a href="https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2018-07-09-taproot-schnorr-signatures-and-sighash-noinput-oh-my/">I previously gave a talk about taproot</a> here I think 1.5 years ago in July 2018. So if you want to know more about the history or the reasoning why we want this sort of thing, then please go have a look at that talk. Here, I am going to talk about a lot of the other things that were brought in that we realized we had to change along the way or that we could and should. I am going to try to justify those things.

So during this talk, I am really going to go over step-by-step a whole bunch of small and less small details that were introduced. Feel free to raise your hand at any time if you have questions. As I said, I am not going to talk so much about taproot as a concept, but this might mean that the justification or rationale for things is not clear, so feel free to ask. Okay.

I think it's important to point out that it's not even-- a question you could ask is, well, but it should be possible to say "optionally introduce a feature that people can use that changes the security assumptions". Probably that is what we want to do at some point eventually, but even--- if I don't trust some new digital signature scheme that offers some new awesome features that we may want to use, and you do, so you use the wallet that uses it, effectively your coins become at risk and if I'm interacting with you... Eventually the whole ecosystem of bitcoin transactions is relying on.... say several million coins are somehow encumbered by security assumptions that I don't trust. Then I probably won't have faith in the currency anymore. What I'm trying to get at is that the security assumptions of the system are not something you can just choose and take. It must be something that really the whole ecosystem accepts. For that reason, I'm just focusing on not changing them at all, because that's obviously the easiest thing to argue for. The result of this is that we end up exploring to the extent possible all the possible things that are possible with these, and we have discovered some pretty neat things along the way.

The balance we end up with is combining some things by focusing on just one thing, and its dependencies, bugfixes and extensions to it, but let's not do everything at once. In particular, we avoid things that can be done independently. If we can argue that doing some feature as a new soft-fork independently is just as good as doing it at the same time, then we avoid it. As you'll see, there's a whole bunch of extension mechanisms that we prefer over adding features themselves. In particular, there will be a way to easily add new sighash modes, and as a result we don't have to worry about having those integrated into the proposal right away. Also new opcodes; we're not really adding new opcodes because there's an extension mechanism that will easily let us do that later.

So we're going to introduce a new witness version. Segwit as defined in bip141 offered the possibility of having multiple script versions. So we're going to use that instead of using v0 as we've used so far, we define a new one which is script v1. Its program is not a hash, it is in fact the x-coordinate of that point q. There's some interesting observations here. One, we just store the x-coordinate and not the y-coordinate. A common intuition that people have is that by dropping the y-coordinate we're actually reducing the key space in half. So people think well maybe this is 1/2 bits reduction in security. It's easy to prove that this is in fact no reduction in security at all. The intuition is that, if you have an algorithm to break a public key given just an x-coordinate you would in fact always use it. You would even use it on public keys that also had a y-coordinate. So it is true that there's some structure in public keys, and we're exploiting that by just storing the x-coordinate, but that structure is always there and it can always be exploited. It's easy to actually prove this. Jonas Nick wrote a blog post about that not so long ago, which is an interesting read and gives a glimpse of the proofs that are used in this sort of thing.

As I said, the output is an x-coordinate directly. It's not a hash. This is perhaps the most controversial part that I expect of the taproot proposal. There is a common thing that people say. They say, oh bitcoin is quantum resistant because it hashes public keys. I think that statement is nonsense. There's several reasons why it's nonsense. First, it makes assumptions about how fast quantum computers are. Clearly when spending an output, you're revealing the public key. If within that time it can be attacked, then it can be attacked. Plus, there are several million bitcoin right now available on outputs that are actually have known public keys and can be spent with known public keys. There's no real reason to assume that number will go down. The reason for that is that really, any interesting use of the bitcoin protocol involves revealing public keys. If you're using lightning, you're revealing public keys. If you're using multisig, you're revealing public keys to your cosigners. If you're using various kinds of lite clients, they are sending public keys to their servers. It's just an unreasonable assumption that.... simply said, we cannot treat public keys as secret.

Of all the different upgrade mechanisms that are in this proposal, OP\_SUCCESS is the one I don't want to lose. The leaf versions can effectively be subsumed by OP\_SUCCESS just start your script with an opcode like OP\_UPGRADE and now your script has completely new semantics. This is really powerful and should make it much easier to add new opcodes that do this or that.

Another is making "minimal IF" a consensus rule. "Minimal IF" is currently a standardness rule that has been in segwit forever and I haven't seen anyone complain about it. It says that the input to an OP\_IF or an OP\_NOTIF in the scripting language has to be exactly TRUE or FALSE and it cannot be any other number or bytearray. It's really hard to make non-malleable scripts without it. This is actually something that we stumbled upon when doing research on miniscript and tried to formalize what non-malleability in bitcoin script means, and we have to rely on "Minimal IF" and otherwise you get ridiculous scripts where you have two or three opcodes before every IF to guarantee they're right. So that's the justification, it's always been there, we're forced to rely on it, we better make it a consensus rule.

# Revisiting squaredness tiebreaker for R point in bip340

XX01: Pieter asked about revisiting the squaredness tiebreaker for schnorr signatures. Do you want to give an overview of that discussion and the end result?

# Bitcoin archaeology

BB: (timestamp your old emails, archaeology....)

# bech32 updates

XX01: Rusty brought up some ideas for how to deal with potential issues with bech32 encoding including the malleability issue discovered a year or two ago at this point with the checksum. Pieter or Rusty, do you want to give a high level overview of this discussion?

# Hold fees

XX01: A little bit of a lightning discussion. I thought this was interesting. This idea of trying to prevent spam on the lightning network, locking up HTLCs, pinging nodes too much, creating a-- requiring payments for actually even doing things in the lightning network. This email is basically positing a few ideas of how to prevent spam on a lightning network. Just a cool conversation.

This problem has gone mainstream recently which is great. The problem here is that we had Alice locked hers first and then Bob locks her. This matters when you're doing a multi-asset bet with HTLC. Usually Alice goes to complete the payment immediately, but what if Alice just sits and watches the price and decides last minute to do it? Alice is getting a free option to execute the transaction. It could be, though, that the price moves and the trade is no longer economic. They could let the HTLC timeout and cancel the trade. In the unlikely event that litecoin market price rises, Alice can complete the transaction and get her new money. This is basically an American-style call option. This is worth a premium, but Alice isn't actually paying that premium in an HTLC. In fact, in lightning, if you bail an HTLC you don't actually pay any fee for it at all. So this is a vulnerability and can be attacked.

# Griefing problem

Christian Decker (CD): Hey Stephan, thanks for having me.

CD: When I wrote up the NOINPUT BIP it was just a bare bones proposal that did not consider or take into consideration Taproot at all simply because we didn’t know as much about Taproot as we do now. What I did for NOINPUT (BIP118) was to have a minimal working solution that we could use to implement eltoo on top and a number of other proposals. But we didn’t integrate it with Taproot simply because that wasn’t at a stage where we could use it as a solid foundation yet. Since then that has changed. AJ went ahead and did the dirty work of actually integrating the two proposals with eachother. That’s where ANYPREVOUT and ANYPREVOUTANYSCRIPT, the two variants, came out. Now it’s very nicely integrated with the Taproot system. Once Taproot goes live we can deploy ANYPREVOUT directly without a lot of adaption that that has to happen. That’s definitely a good change. ANYPREVOUT supersedes the NOINPUT proposal which was a bit of a misnomer. Using ANYPREVOUT we get the effects that we want to have for eltoo and some other protocols and have them nicely integrated with Taproot. We can propose them once Taproot is merged.

# RBF pinning

SL: From watching the Bitcoin dev mailing list, I saw some discussion around this idea of whether the Lightning node should also be looking into what’s going on in the mempool of Bitcoin versus only looking for transactions that actually get confirmed into the chain. Can you comment on how you’re thinking about the security model? As I understand, you’re thinking more that we’re just looking at what’s happening on the chain and the mempool watching is a nice to have.

# SIGHASH flags

Bastien Teinturier at Lightning Conference: https://diyhpl.us/wiki/transcripts/lightning-conference/2019/2019-10-20-bastien-teinturier-trampoline-routing/

SL: That’s a very good comment there. I wanted to talk about trampoline routing. You mentioned this earlier as well. I know the ACINQ guys are keen on this idea though I know that there has also been some discussion on GitHub from some other Lightning developers who said “I see a privacy issue there because there might not be enough people who run trampoline routers and therefore there’s a privacy concern there. All those mobile users will be doxing their privacy to these trampoline routers.” Do you have any thoughts on that or where are you placed on that idea?

Audio: https://stephanlivera.com/episode/260/

Transcript by: Stephan Livera Edited by: Michael Folkson

SL: So let’s move on to Taproot now. We’ve got this new soft fork that most people want. There’s been no serious sustained objections to it. Can you spell out your thoughts on how Taproot activation has gone so far?

LD: The lockintimeout=true is essentially what we ended up having to do with SegWit. It gives a full year to the miners so they can collaborate cooperatively and protect the network while it’s being activated early. If the miners don’t do that for whatever reason, at the end it activates. If we were to set lockinontimeout=false we essentially undo that bug fix and give miners control again. It would be like reintroducing the inflation bug that was fixed not so long ago. It doesn’t really make sense to do that. At the end of the day it is a lot less secure. You don’t really want to be running it as an economic actor so you would logically want to run lockinontimeout=true. Therefore a lot of economic actors are likely to run it true. In most of the polls I’ve seen most of the community seems to want true. As far as a flag day, that’s essentially the same thing as lockinontimeout=true except that it doesn’t have the ability for miners to activate it early. So we’d have to wait the whole 18 months for it to activate and it doesn’t have any signaling. At the end of the day we don’t really know if it activated or if the miners are just not mining stuff that violates Taproot which is the difference of whether it is centralized or decentralized verification. It is economic majority still, that will matter for the enforcement, but you want to be able to say “This chain has Taproot activated.” You don’t want it to be an opinion. I say Taproot is activated, you say it isn’t. Who’s to say which one of us is right? Without a signal on the chain we’re both in a limbo where we’re both saying the same thing about the same chain and there’s no clear objective answer to that question, is Taproot activated.

# Bitcoin Core releasing LOT=false and UASF releasing LOT=true

SL: The other argument I have heard is if Bitcoin Core were to release a client with LOT=false and another contingent of developers and users who want to go out and do similar to the UASF and release an alternate client with LOT=true. The average user can’t review all the Bitcoin code and they would now have to decide whether they want to run this alternate client that does include LOT=true. So what are your thoughts on that aspect?

# Dealing with unlikely chain splits

# Speedy Trial

Speedy Trial support: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f

# PTLCs (lightning-dev mailing list)

This is the mailing list post from Nadav Kohen summarizing a lot of the different ideas about PTLCs.

There was a question on IRC yesterday about a specific mailing list post on one party ECDSA. Are there different schemes on how to do adaptor like signatures with one party ECDSA?

# On the scalability issues of onboarding millions of LN clients (lightning-dev mailing list)

Antoine Riard was asking the question of scalability, what happens with BIP 157 and the incentive for people to run a full node versus SPV or miner consensus takeover.

This conversation happened on both the bitcoin-dev mailing list and lightning-dev mailing list.

This sums up my feelings on it. There were a lot of messages but I would definitely recommend reading John’s one.

The argument is really about do we want to make light clients not too good in order to disincentivize people to use them or do we not want to do that? It also comes down how do we believe the future will play out. That’s why I would recommend people to read Nicolas Dorier’s article and look at the arguments. It is important that we still think about these things. Maybe I am on the side of being a little more optimistic about the more future. That more people will run their own full nodes still or enough people. I think that is also because everyone will value their privacy will want to run a full node still. It is not like people will forget about that because there is a good light client. I honestly believe that we will have more full nodes. It is not like full nodes will stay at the same number because we have really good light clients.

This is the PGP model. When PGP first came out it was deliberately hard to use so you would have to read documentation so you wouldn’t use it insecurely. That was a terrible idea. It turns out that users who are not prepared to invest time, you scare off all these users. The idea that we should make it hard for them so they do the right thing, if you make it hard for them they will go and do something else. There is a whole graduation here. At the moment a full node is pretty heavy but this doesn’t necessarily have to be so. A full node is something that builds up its own its own UTXO set. At some stage it does need to download all the blocks. It doesn’t need to do so to start with. You could have a node that over time builds it up and becomes a full node for example, gradually catches up. Things like Blockstream’s satellite potentially help with that. Adding more points on the spectrum is helpful. This idea that if they are not doing things we like we should serve them badly hasn’t worked already. People using Electrum random peers and using them instead. If we’ve got a better way of doing it we should do it. I’ve always felt we should channel the Bitcoin block headers at least over the Lightning Network. The more sources of block headers we have the less chance you’ve got of being eclipsed and sybil attacked.

There are certainly more things we can do. The truth is that people are running light clients today. I don’t think that is going to stop. If you really want to stop them work really hard on making a better full client than we have today.

This was what happened with SegWit2x, aggressively going after the SPV wallets. They were like “We are going to carry all the SPV wallets with us”. It is a legitimate threat. There is an argument that if you have significant economic weight you should be running a full node, that is definitely true. But everyone with their little mobile phone with ten dollars on it is maybe not so important.

We would love to get out of the wallet game. PSBT to some extent lets us do that. PSBT gives us an interoperable layer so we can get rid of our internal wallet altogether and you can use whatever wallet you want. I think that is where we are headed. The main advantage of having normal wallets understand a little bit of Lightning is that you could theoretically import your Lightning seed and get them to scrape and dredge up your funds which would be cool. Then they need to understand some more templated script outputs. We haven’t seen demand for that yet. It is certainly something that we have talked about in the past. A salvage operation. If you constrain the CSV delay for example it gets a lot easier. Unfortunately for many of the outputs that you care about you can’t generate all from a seed, some of the information has to come from the peer. Unless you talk with the peer again you don’t know enough to even figure out what the script actually is. Some of them you can get, some of them are more difficult.

It has to be stateful anyway because you have to have multiple rounds. If you want to let them negotiate with multiple parties they are not going to know everything upfront. I send to Alice and Bob “Here’s things I want to add.” Then Alice sends me stuff. I have to mirror that and send it to Bob. We have to have multiple rounds. If we are going to have multiple rounds keep the protocol as simple as possible. Add, remove, delete. We don’t care about byte efficiency, there is not much efficiency to be gained. A simple protocol to just have “Add input, add input, add input” rather than “Add inputs” with a number n. It simplifies the protocol.

This one was on soft fork deployment.

What was discussed on the mailing list at the start of the year was as Luke says was BIP 9 plus BIP 149. BIP 149 was going to be the SegWit activation which expires in November, we’ll give it a couple of months and then we’ll do a new activation in January 2018 I guess that will last a year. There will be signaling but at the end of that year whether the signaling works or not it will just activate. It divides it up into two periods. You’ve got the first period which is regular BIP 9 and the second period is essentially the same thing again but at the end it succeeds no matter what. The difference between that and BIP 148 is what miners have to do. What we actually had happen was before the 12 months of SegWit’s initial signaling ended we said “For this particular period starting around August miners have to signal for SegWit. If they don’t this hopefully economic majority of full nodes will drop their blocks so that they will be losing money.” Because they are all signaling for it and we’ve got this long timeframe it will activate no matter what. It will all be great. The difference is mostly BIP 148 got it working in a shorter timeframe because we didn’t need to have to start it again in January but it also forced the miners to have this panic “We might be losing money. How do we coordinate?” That was BIP 91 that allowed them to coordinate. The difference is that BIP 148 we know has worked at least once. BIP 149 is similar to how stuff was activated in the early days like P2SH. But we don’t know 100 percent it will work but it is less risk for miners at least.

The next step is going to be doing the actual swap. What we want here is the opposite to happen. Instead of AS being revealed and Alice getting her money back we want Bob to get the money and BS to get revealed to Alice. How do we do that? We create another transaction to Bob and that transaction if Bob sends to the blockchain will reveal BS. Because this one has no timelocks it happens before everything else we have created thus far. This enables the swap. Now if this transaction goes to the blockchain, BS is revealed, Alice already knowing Alice’s secret and now also knowing Bob’s secret gains control over the transaction on the Litecoin side. Bob if he has sent this to the blockchain, now he has the money on the Bitcoin side. This is a three transaction protocol. The main point here is that this already better than the original atomic swap. With the original atomic swap you would have 4 transactions. Here on the bottom side, nothing happens. It is just one single transaction and the key is split into two parts. Either Bob gets it or Alice gets it because they give one of the parts to each other. The next step would be how to turn this into a 2 transaction variation. What we do is we don’t broadcast this transaction at the top. We give it to Bob but Bob doesn’t broadcast it and instead Bob just gives Bob’s secret to Alice. Bob knows he could broadcast it and get the money, he is guaranteed to receive it but he doesn’t do so and he just gives the secret to Alice. Alice now has control over the Litecoin transaction and Bob if he sends that transaction to the blockchain would also get control over the Bitcoin transaction. However instead of doing that Alice gives Alice’s key to Bob. Now the swap is basically complete in two transactions. They both learn the secret of the other person on the other side of the chain. This would literally be a 2 transaction swap. But there is still this little issue of this transaction existing where Alice gets her money back. This timelocked transaction still exists. What this means is that even though the protocol has completed in 2 transactions there is still a need for Bob to watch the blockchain to see if Alice tries to get her money back. The way the timelocks are set up, particularly with this relative timelock at the end there, what this means is that Alice can send this middle transaction A+B (1 day lock) to the blockchain but in doing so Bob will notice that the transaction goes to the blockchain. Since Bob has Alice’s key he can spend it before the third transaction becomes valid. Bob will always be able to react just like a Lightning channel where one party tries to close the channel in a way that is not supposed to happen. The other party has to respond to it. It requires Bob to be online in order for this to be a true 2 transaction setup.

What exactly are the requirements for the alternative coin? It doesn’t need to have timelocks, does it need Script?

# CoinSwap

It is looking at how we can use atomic swaps in such a way that we increase privacy. It goes through different setups you can create. One of them would be on one side you give somebody 1 Bitcoin and on the other side you give somebody 3 UTXOs, 0.1, 0.2 and 0.7. You can do these fan out swaps and you can make swaps depend on other swaps. You can do swaps in a circle where Alice gets Bob’s money, Bob gets Carol’s money, Carol gets Alice’s money and things like that.

I think it can be split up. You could have the same amount but from different chunks.

That is definitely a big use case of atomic swaps. Say you want to use zero knowledge proofs on Zcash or use Monero to get some privacy with your Bitcoin and then get it back into Bitcoin. Does that bring strong benefits? Or use a sidechain with confidential transactions on it. This seems like a useful use case.

This is one of the issues I really wanted to know more about. It has obviously been discussed because it is the same way eltoo works?

You can actually circumvent this problem in eltoo?

# BIP 118 and SIGHASH_ANYPREVOUT

Is anyone not familiar with NOINPUT/ANYPREVOUT as of a year ago, basic concept?

# Thoughts on soft fork activation (AJ Towns)

There are a billion points under this topic that you could probably talk about forever. Obviously talking about things forever is how we are going at the moment. We don’t want to have Bitcoin be run by a handful of developers that just dictate what is going on. Then we have reinvented the central bank control board or whatever. One of the problems if you do that is that then everyone who is trying to dictate where Bitcoin goes in future starts putting pressure on those people. That gets pretty uncomfortable if you are one of those people and you don’t want that sort of political pressure. The ideal would be that developers think about the code and try to understand the technical trade-offs and what is going to happen if people do something. Somehow giving that as an option to the wider Bitcoin marketplace, community, industry, however you want to describe it. The 1MB soft fork where the block size got limited, Satoshi quietly committed some code to activate it, released the code seven days later and then made the code not have any activation parameters another seven days after that. That was when Bitcoin was around 0.0002 cents per Bitcoin. Maybe it is fine with that sort of market cap. But that doesn’t seem like the way you’d want to go today. Since then it has transitioned off. There has been a flag day activation or two that had a few months notice. Then there has been the version number voting which has taken a month or a year for the two of those that happened. Then we switched onto BIP 9 which at least in theory lets us do multiple activations at once and have activations that don’t end up succeeding which is nice. Then SegWit went kind of crazy and so we want to have something a little bit more advanced than that too. SegWit had a whole lot of pressure for the people who were deeply involved at the time. That is something we would not like to repeat. Conversely we have taken a lot more time with Taproot than any of the activations have in the past too. It might be a case of the pendulum swinging a bit too far the other way. There is a bunch of different approaches on how to deal with that. If you read Harding’s [post](https://gist.github.com/harding/dda66f5fd00611c0890bdfa70e28152d) it is mostly couched in terms of BIP 8 which I am calling the simplest possible approach. That is a pretty good place to start to think about these things. BIP 8 is about saying “We’ll accept miners signaling for a year or however long and then at the end of the year assuming everyone is running a client that has lock in on timeout, however that bit ends up getting set, we’ll stop accepting miners not signaling. The only valid chain at that point will have whatever we’re activating activated.” Matt’s modern soft fork activation is two of those steps combined. The first one has that bit set to false and then there is a little bit of a gap. Then there is a much longer one where it is set to TRUE where it will activate at the end. There are some differences in how they get signaled but those are details that don’t ultimately matter that much. The decreasing threshold one is basically the same thing as Matt’s again except that instead of having 95 percent of blocks in a retarget period have to signal, that gradually decreases to 50 percent until the end of the time period. If you manage to convince 65 percent of miners to signal that gives you an incremental speed up in how fast it activates. At least that way there is some kind of game theory incentive for people to signal even if it is clear that it is not going to get to 95 percent.

As a relative newcomer to the space, I thought that the whole Taproot process was handled magnificently. The open source design and discussion about it was so much better than any other software project in general that I have seen. That was really good and that seems to have built a lot of good support and goodwill amongst everyone. Although people may enjoy discussing all the different ways of activating it it feels like it will get activated with any one of those processes.

Is the first blocker getting that [Schnorr PR](https://github.com/bitcoin-core/secp256k1/pull/558) merged into libsecp? That code is obviously replicated in the Bitcoin Core Taproot PR. But is that the first blocker? Get the libsecp PR merged and then the rest of the Taproot Core PR.

Rusty presenting at Bitcoin Magazine Technical Tuesday on lnprototest: https://www.youtube.com/watch?v=oe1hQ7WaX4c

This testing suite allows people to develop a feature… would that help them check compatibility against another implementation for example?

# Dynamic Commitments: Upgrading Channels Without Onchain Transactions (Laolu Osuntokun)

We had this item here on upgrading channels without an onchain transaction. This is a roasbeef post. It is talking about how you could upgrade a channel. One example was around changing the static remote key.

# PoDLEs revisited (Lloyd Fournier)

We’ll start with me talking about my research into UTXO probing attacks on Lightning in the dual funding proposal. I will go quickly on it because there are a lot of details in that post and they are not super relevant because my conclusion wipes it all away. I think we’ve discussed this before if you are a long time Sydney Socratic attendee, maybe the first or second meeting we had this topic come up when the dual funding proposal was first made by Lisa from Blockstream. This is a proposal to allow Lightning channels to be funded by two parties. The reason for doing that, both parties have capacity at both sides. Both sides can make a payment through that channel right at the beginning of the channel. The difficulty with that is that it creates this opportunity for the person who is requesting to open the channel, say “I am going to use this UTXO”, wait for the other guy to say “I will dual fund this with you with my UTXO” and then just leave. Once the attacker has learnt what UTXO you were going to use he now knows the UTXO from your wallet and then just aborts the protocol. You can imagine if you have a bunch of these nodes on the network that are offering dual funding the attacker goes to all of them at once and just gets a bunch of information about which node owns which UTXO on the blockchain and then leaves, does it again in a hour or something. We want to have a way to prevent this attack, prevent leaking the UTXOs of every Lightning node that offers this dual funding. We can guess that with dual funding, probably your node at home is not offering that, maybe it is but you would have to enable it and you would have to carefully think about what that meant. But certainly it is a profitable thing to do because one of the businesses in Lightning is these services like Bitrefill where you pay for capacity. If anyone at home with their money could offer capacity in some way to dual fund it might become a popular thing and it may offer a big attack surface. One very intuitive proposal you might think of is as soon as this happens to you, you broadcast the UTXO that the attacker proposed and you tell everyone “This guy is a bad UTXO”. You shouldn’t open channels with this guy because he is just going to learn your UTXO and abort. Maybe that isn’t such a great idea because what if it was just an accident? Now you’ve sent this guy’s UTXO around to everyone saying “He is about to open a Lightning channel”. Maybe not the end of the world but the proposal from Lisa is to do a bit better using a trick from Joinmarket which is this proof of discrete logarithm equality or we’ve called it PoDLE. What this does is creates an image of your public key and UTXO against a different base point. It is fully determined by your public key, by your secret key, but it cannot be linked to your public key. It is like another public key that is determined by your public key but cannot be linked to it unless you have a proof that links the two. What you do is instead of broadcasting a UTXO you broadcast these unlinked coins. No one can link to the onchain UTXO but if that attacker connects to them they’ll be able to link it.

# Lightning dice (AJ Towns)

Slides: https://www.dropbox.com/s/xborgrl1cofyads/AJ%20Towns-%20Lightning%20Dice.pdf

# Taproot activation

Let’s talk about Taproot activation so we can actually have this thing working on mainnet.

You could do the PTLCs and just not do the randomization bit of it. There are other ways you can leverage PTLCs. I don’t know if I would say I would not do it but it is definitely worth the Lightning developers considering this problem before switching I would say. It is the operating nodes that have to pay the cost for this protocol change. Of course they can just not accept that if they don’t want to, it can be an optional thing.

This is the particular one about fees. He writes a lot about [Lightning problems](https://github.com/ariard/L2-zoology) but he is also doing a workshop on this fee bumping, what should be the rules to evict transactions from the mempool? I have a Bitcoin problem as a [PR](https://github.com/bitcoin-problems/bitcoin-problems.github.io/pull/13) right now on that topic as I’m trying to teach myself and he has done a nice review for me. I need to go through that. Eventually there will be a Bitcoin problem on solving that. If we solve this problem out of these meetings then it can be the first Bitcoin problem to be solved.

# Designing Bitcoin Smart Contracts with Sapio (Jeremy Rubin)

I’ve got this [blog post](https://judica.org/blog/sapio-tutorial/), this is being released by Judica which is a research lab / development team started by Jeremy Rubin. Their first big release is this Sapio language, this Sapio compiler for the language. It is a smart contract compiler but smart contract doesn’t necessarily mean one transaction. It is a contract that could be expressed through many transaction trees. What’s the angle here? I have taken a look at this blog post. What he has got here is a really basic public key contract which means these funds can be taken by making a signature under somebody’s public key.

Agenda: <https://github.com/bitcoin-sydney/socratic/blob/master/README.md#2021-07>

# Basics and BIP 125 RBF

# Future ideas - SIGHASH_IOMAP and fee sponsorship

This needs a soft fork and as you say it is on crack because it is not a CPFP or a RBF. It is literally a transaction that has no relation whatsoever to the transaction you are concerned about. There is no connection whatsoever, that high fee transaction is saying “You can only mine me if you also include this other transaction that is not related.”

# Transaction mutation proposal

There was an alternative proposed solution, it was semi failed. The idea was to allow you to change transactions after they’ve been signed, to mutate them. Outputs tend to go towards one party or the other so one party can reduce one of the outputs after it has been signed. If we put a Tapscript in there that says “Under these conditions this output can be reduced with a signature from this key.” That would increase the fee. The problem with that idea is that in layer 2 protocols the outputs are not owned exclusively by one party yet. Or at least as soon as the commitment transaction is broadcast you don’t know who owns those funds even if they are in a `to_self` output or a `to_remote` output. In the `to_self` case you don’t know who they are going to yet. How do you decide where they get the funds from to reduce an output? You have to put some kind of limit in there, you can reduce this output by this amount. If you set that limit too high you can do a griefing attack where you broadcast an old commitment transaction in a channel you no longer have much interest in and burn a large fee to a miner to grief the other person. What is the logic to set the limit of the fees you can reduce? The advantage of this mutation scheme is clearly you do not need coins from outside the protocol coins. The coins that went into the channel in the first place, you can use those coins to bump the fee rather than getting them from the wallet. My concern is that is difficult from a UX perspective to always have coins around. It would be a nice thing to get rid of, you could just use the channel coins to bump the fee but it turns out to be rather involved. I am thinking that one of these two proposals is probably better.

MB: I feel like it was this time last year.

MC: I just have Michael’s notes as well. It seems like people are coming round to just doing the miner readiness signaling thing.

# Wasabi Research Club

# CoinSwaps (Belcher 2020)