Introduction

We're bitdevs and we're not going to talk about FTX today. We don't talk about price or scammers. We talk about interesting technical things happening in the community whether they are proposals are things that are released. FTX might not be on this site, but there are other companies still hiring.

We have a few announcements. Bitcoin++ will be having a conference in Mexico City. I am running a conference in Mexico City in December. I am excited about this conference. What's so exciting is that it's bitcoin++'s first international conference which is going to be great. The other thing super cool about it is that the focus is going to be "on-chain privacy". What that means is that we have speakers from all of the big privacy-focused wallets and projects that are going to be there. We have people from Samurai, Wasabi, joinmarket protocol, some people who did-- the guy who wrote the anonymity set thing that worked on Monero. I know it's bitcoin++ but big umbrella; the idea is thaT I don't know all as much as I want to know about how on-chain privacy protocols work so I invited those people to Mexico City in 3 weeks and we will talk about it and hopefully we will have lots of workshops and hands-on things and we will learn how on-chain privacy works and things to think about. It will be fun. Everyone is going to get noche libre masks for participating. It should be a good time. Mexico City is actually a lot cheaper than having a conference in Austin.

This upcoming semester, ECE 382V will be bitcoin-only even though it says "Blockchain and Smart Contracts". If you want to keep Austin being the hub of bitcoin and keep the relationship with the university and see this class continue, then we need a university liason who has university-friendly credentials. Are any of my students here tonight? Fail. We need a champion that has PhD-or-equivalent credentials who can teach the class. They get employed by the university and get paid for this, even if they don't actually give the lectures. Who here is a PhD bitcoiner? The PhD can be in anything. Dhruv is a physicist who might be interested- but he's not based in Austin anymore unfortunately. Come find me after and help me please. Reach deep and see if you know anyone. One of the things we try and do with bitdevs and the content that we pick or that Lisa does with her programs, the education is important. In the public, you hear people complain that bitcoin is boring. It means that the other protocols that shall not be named attract people early on because they feel that's more exciting. Having events like this is important to make sure we continue to improve bitcoin and make it more resilient. We should not get lazy about this stuff. We want then to rename it to "Bitcoin and Script" or "Elements and Liquid" or "bitcoin programming".

Burak's hellscape: lnd broke again

So, lnd broke again. Issue 7096. If you remember last month, lnd broke and then 2 weeks later lnd broke again. I thought this was 2 months ago, but it was only 17 days ago. It's been a long month. Oh there he is, there's Ryan. This is similar to the last one. It was a bug introduced during lnd/btcd's implementation of segwit because of the taproot upgrade. Last time it was about the script size. This was the witness items; if you put 500,001 witness stack items then lnd wouldn't be able to parse it. This wasn't an lnd bug like last time, it was a bug in rust-bitcoin as well. A lot of things downstream from rust-bitcoin broke, like BDK, some Liquid stuff, electrs, etc. It was a little bit far more reaching bug this time. Future versions had been patched, but not previous versions.

I just got back from the bitconf in Argentina. What's really interesting about these bugs is that the reason they are breaking is someone is taking a transaction and publishing it to the blockchain. As soon as that gets into the blocks, there are block processors that try to read all the data and these things are breaking. All you're doing in this attack is getting a certain transaction mined. Usually to attack a system you have to breach someone's system. There's nothing lightning-specific about this. This is just some dude building a transaction and then paying a miner to get it into a block. Because the block bitcoin system is a broadcast system, it takes that mined transaction and it goes out to every bitcoin node on the network and then it gets "validated" which is breaking.

The second one is interesting; someone in Argentina was saying this transaction was invalid or something. But that's not correct. If you are hearing that it was an invalid transaction, that's not what happened. It was just non-standard which just means that getting it to a miner is hard. The only way to get it to a miner if it's non-standard is by going to a miner and asking them to please mine this transaction through some sort of out-of-band negotiation thing. I think this guy literally emailed the miner the transaction in this case. If it was an invalid transaction, then any block with that transaction would also be invalid and therefore it would not be added to the chain. This was a valid transaction that, for hand wavy reasons, is "non-standard" and hard to get it to the miner unless you like email them. This is pretty interesting. It's not invalid. It's perfectly valid, it's just not "standard". There's a whole section in taproot where it lists all the changes they made; I looked at a video I made from a taproot conference in June, and I was scrolling through the docs and I was looking through all the resource constraint changes- it's on twitter if you want to see how those bugs are being exploited. There's a video where I talk about the changes in taproot.

I think there was some drama around the disclosure of this particular bug. Bugs exist. They will always exist and we are always going to find new bugs. The effort to get this non-standard transaction into a block was not an oopsie, someone put in effort to get this into the blockchain. As someone who runs a production lnd node, I had to deal with the consequences of that and sure maybe you should just deal with it because it's an anti-fragile network and it sucks to suck, right? Or maybe we should have responsible disclosure pathways.

I previously worked on a javascript implementation of a bitcoin node, and we discovered some DoS vectors. If there are no actual generally agreed upon responsible disclosure processes, then what's the right approach? Maintainers of projects have a lot of responsibilities and there's different levels of bugs, like 0days where as soon as this is discovered everything can be brought down, or there's expensive DoS vectors- so how important are those? With different disclosure policies, one of the things that is important is balancing this out. If you are in charge of a project and you get told about a security bug, how long should you have to fix it? How long should you be given to try to fix it before you are hurting userS? At that point, now well I can go out in the world and tell anyone about it or exploit it myself as a way to force someone to fix it. Should it be a few weeks? A few months? Years? Should you tell others about it or not? It's really tricky. How much responsibility does the bitcoin community have to responsibly dislcose to other forks of bitcoin like altcoins like litecoin? Normal people invested in these coins, and they get impacted. Sure, anti-fragile and whatever, but it has to be balanced.

Burak wrote this to break lnd, but it broke Liquid which is what his company is built on top of. It broke something in Liquid. It's a hard problem to solve. Bugs have always existed and you have to work around this problem. Also, in the OP_RETURN he wrote "you will run core-lightning and you'll be happy". He also said he will keep doing it, so everyone should keep that in mind.

The wire parsing library in btcd that gets called in, was not hit with all the test vectors which it probably should have in retrospect. Even if you were running behind a bitcoind node, you would still be hit by this problem.

Bitcoin Core taproot has a humongeous test vector file for testing. The bug in lnd only exists where you parse a block with this kind of transaction, so the test vectors might not have caught it. It's a very niche bug to find. In the wild, it could happen, and that's why lnd broke. If the transaction is non-standard, then people are like ehh it doesn't matter that much. It was disclosed to lnd a week prior but people didn't really care or think it would be a problem.

You often need to release bugfixes in a non-public way because you need to give people some time to upgrade before too many potential attackers learn about it. Often you have to patch it in a semi-secret way where you hide it in other commits with other stuff, and you need to give people enough time to upgrade without saying "UPGRADE NOW OR ELSE YOU ARE HACKABLE" which means you need to give a ton of lead time.

It's a tough thing, especially because these bugs were basically back-to-back which nobody is happy about. Processes have been put in place to make sure this doesn't happen again. The week prior, the first one was disclosed and the plan was to slip the fix into a new version of btcd so that people who didn't upgrade wouldn't be vulnerable to an exploit. That's the right strategy to protect users, if you are afforded the time to be able to slip the fix in, because on the alternate side if you are to immediately release a patch and say oh well we just had an out-of-nowhere upgrade to btcd then people who are looking to exploit it will go look at the fix, see that it came out of nowhere, and then figure out that maybe it's a security hole and they might be able to attack people. It's a tricky thing to release these fixes. I identify with the anti-fragile approach and I understand the sentiment around that, but on the other hand at the end of the day there are real people running these nodes with their real money so you have to think about them too not just the authors of the software. That's why we have responsible disclosure in open-source software. It's a tricky grey area and some moral/ethical questions here. Hopefully it's a question that Lightning Labs doesn't have to deal with again.

.... historically with layer 1 bugs, the mining pools solved this problem where if you have a potential vulnerability regarding a non-standard transaction then you would get a majority of hashrate to download the upgrade and then suddenly the attack becomes non-viable, which we saw in the inflation bug in bitcoin. It was not able to be exploited because the mining pools patched their software. It's interesting how that worked. Hashrate was able to protect things a little bit. But even in the rocksdb/leveldb upgrade, the neat way to solve the problem was to reorg the chain. So you have that extra lever on layer 1 where you can mine on a certain side of history and then that becomes fact.

bip324: p2p encryption

https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2022-10-10-p2p-encryption/

Bitcoin's gossip protocol is entirely plaintext and has no encryption right now. The bitcoin protocol has multiple layers. The gossip layer is where p2p nodes are passing messages back and forth to each other. When it comes to the bitcoin gossip protocol, it's this network where messages are passed around, so if it's public you might as well have it not encrypted, right? So why consider any overhead or computational overhead for encryption? Why insert encryption into the gossip network if everything is going to be public in the end? Well, it turns out that's wrong, especially in adversarial situations. There are some attacks you can imagine on the gossip protocol, like tracking where transactions originate, eclipse attacks, saturating a node's connection, selfish mining attacks, figuring out where wallets are located, figuring out which nodes are connected to each other, etc. It can also reveal where you are in the p2p graph which is not necessarily something you want surveillance to be able to figure out.

Sybil nodes will attempt to have as many connections with discrete nodes as possible. When an originating nodes broadcasts a transaction, a Sybil attacker would be able to infer who the source of the transaction is. If you have a global passive adversary, like the NSA, where they observe literally all the traffic in the network, then they can figure out which node is the first one to broadcast a transaction and therefore which one is the originator of the transaction. Also, internet service providers or other network service layers can intercept traffic and do deep packet inspection or other analysis. There's censorship, adversarial modification in pursuit of partitioning the network, surveillance, privacy issues, etc.

bip324 is basically the successor to bip150 by jonasschnelli. Authentication is not included. Encryption is included. We don't want to super duper increase network overhead. The first thing they did was come up with an encryption scheme based on curve secp256k1. There's no pairing cryptography here or any additional cryptographic assumptions. On the wire, the bytes are pseudorandom.

....

tor does a lot of work to hide traffic and make it really hard to profile tor traffic. It should be really hard to censor bitcoin traffic. I don't want to take any credit for this remotely. We want the gossip network to be censorship resistant, yes. Every jurisdiction will have it own unique censorship adversaries, some that are more or less sophisticated than others. Tor will have bridges, for example, that you connect to and get into the network that way. Bitcoin has a lot to learn from tor and tor has a lot to learn from bitcoin. In lightning today there is the blinding paths protocol where you can have receiver privacy which uses rendevouz protocol which is kind of like tor's hidden services protocol.

One of my favorite attacks in bitcoin, which might happen one day, is an ISP siphoning off a tiny percent of all miner's hashpower using the stratum protocol. Traditionally the answer to this attack is to use stratum v2 which so far not many people are using. There was a BGP hijack attack that stole a bunch of hashrate in 2013. The stratum protocol is not encrypted. There was a BGP router that was hijacked, and hashrate was re-routed by the attacker. The pool sends the shares over the wire to the clients and it's totally unencrypted in stratum v1 so it's subject to man-in-the-middle. You can steal work from another worker in the pool, and if you only steal 1% then you can probably get away with it for months because nobody would be able to tell they are just not unlucky. Hopefully stratum v2 gets adopted sooner rather than later.

Zero-conf statecoin channels

I also want to talk about layering a lightning channel on top of a statechain. I've been working on this with Ruben Somsen and Mercury Wallet which is an implementation of the statechains protocol which is focused on privacy. It's like a coin swap facility. They can swap private keys anonymously. Who here has heard of statechains before? Most people, great. How many have heard about opendime? A statechain is a virtual opendime with a trust model that allows you to pass around a private key. The trust model sits between Liquid and Lightning. Liquid is a pure federation, and Lightning has a liveness requirement. In statechains, there's a little bit of both. Alice works with the statechain entity to cooperatively generate a shared keypair and have a half key. Before depositing funds, Alice gets a backout transaction with a timelock. She deposits her funds into the statechain, and if the statechain entity disappears, she can get it out at any time. Bob first creates a backout transaction with a decremented timelock, and then Alice can send to Bob. After the transaction between multiple parties has occurred, Alice could collude with the statechain entity and steal the funds. It's provable on-chain, and Mercury statechain has mechanics to make this visible to everyone. The tradeoff of statechains is the decrementing counter, unless we get eltoo activated.

What happens if you combine statechain and lightning? Statechain is about keys, and lightning is about scripting. One of the problems with lightning is onboarding users, they need to make a channel, and there are also some liquidity problems about moving funds around. When you take lightning and build a lightning channel on top of a statechain coin, you allow yourself to break a statechain down to small parts, and allows you to move a lightning channel off-chain. Alice could just buy a lightning channel off-chain using this statechain mechanism. I could give someone the private key to a lightning channel. My BLiP describes how to do this.

There are a few ways to do a lightning channel on top of statechains, but the simplest way is that backout transaction has an output but what if it created a lightning channel as opposed to a classic pay-to-pubkeyhash script, but what if you constructed a lightning channel in this backout or peg-out transaction? Well, nobody sees this on-chain. Lightning channels are on-chain, right? This is a derivative of the zero-conf channel paradigm. Have you heard about zero-conf channels? Unconfirmed transactions. This is not an unconfirmed transaction in the classic sense; it has a perjorative connotation so maybe we won't use that name.

The underlying statecoin can be passed around off-chain. There are some tradeoffs- you need the cooperation of the statechain entity to create the channel. Just like in Liquid, you have a federation. Once the channel is created, Alice and Bob can send funds back and forth. If the statechain entity disappears, then Alice and Bob need to go on-chain with the backout transaction which has a timelock which can break HTLCs. If the statechain entity remains around, Alice and Bob can push funds back-and-forth in the channel, then reopen the channel with a new counterparty.

You can't interact with the normal lightning network. There might be ways to announce it. Not everone needs to support it, though, because this is just a two-party thing. If one party in the channel does, then you can access the rest of the lightning network. You could specify this in the TLVs and have a special zero-conf route channel feature bit. Any more questions? Lightning at the edges, that's what everyone calls it.

Replace-by-fee (RBF)

If you've been on twitter, you have seen stuff about FTX but also stuff about RBF. Bitcoin Core cut release v0.24 today. There was some drama in the release process about this new flag to allow for full RBF. Previously in Bitcoin Core by default you would need to signal replacement to tell people hey this transaction this is unconfirmed but replace it in the future if I broadcast something with a better fee-rate and that's the one I want. The mempool policy comes into play here. As part of the process of getting away from it, the proposal was to add a default-off flag on Bitcoin Core to let your mempool say all transactions are RBF no matter whether they signal or not. Everything was going well, until people on twitter found out. Bitrefill and Moon have entire business models that rely on zero-conf transactions which don't work. Lots of people have been telling them it's not actually secure. And also, you can always just email a transaction to a miner to get it mined. We're trying to move things to a more incentive-compatible state.

petertodd put up a bounty for this. He's an advocate for full RBF. So every block, he broadcasts a transaction and then he replaces them with full RBF fees. He's basically bribing miners to turn this on. If the ydo, then the miners get some money. He did some math and found that miner's margins are pretty small, so $50 might actually really matter for miners. The miners don't even have to turn on RBF, they can just accept the RBF transaction even if their mempool doesn't work that way.

There's a few different types of replace-by-fee. This goes back to the early days of bitcoin lore. Satoshi had an idea for a transaction replacement scheme but it didn't have any DoS protections. You could just for free replace transactions constantly. There's no cost to broadcasting transactions. The cost for transactions is in getting mined, not broadcast. One of the things we fought about for small blocks is that this is a cost for all nodes everywhere and you want to prevent nodes to store too much information, but if you let anyone broadcast any transaction as much as they want then now these nodes need to track all those different versions of the transactions.

bip125 is opt-in replace-by-fee. One of the documented rules is that you have to set a flag, tweak some bytes in the transaction to indicate that you would like your transaction to be replaceable as long as the replacing transaction pays sufficient fee, no unconfirmed inputs, and a few other rules. Then there's full RBF which does not require you to signal it ahead of time. Why might you want the full RBF versus the not full? Why opt-in versus not? Well, some users were using zero-conf transactions which aren't safe, and so they were arguing that doing this other stuff would harm them more than the harm they were already perpetuating on themselves by doing something stupid and insecure.

Do other nodes know which other nodes have that flag turned on? Antoine Riard has a PR where you can signal that. His idea is that you want a diversity of -- some nodes connect to some, some that signal and half that don't. Lightning nodes probably have a signal for zero-conf? There's a bit flag, yes. But this is mempool replacement, which is different.

I have a bit of a trolly question. Does Bitrefill do any mining? They are one of the large miners in the space that would not like to see full RBF. Is anyone here against full RBF? The best argument would be that the only use is malicious. There's no honest good use of full RBF, but this is a broken assumption. The steelman is that you guys are a bunch of nerdy core developers who are up in your ivory tower and I'm just a helpless gift card purchasers and you're messing with my life when I'm trying to buy my xbox live and taco bell gift cards. Trolling aside, the important thing to keep in mind is that the goals of this is that I want a mempool that resembles what a miner is going to mine in the next block. If you can't do that, then you can't do accurate fee rate estimation for my own transactions and your transaction will constantly have too low of a fee-- oh well that's simple, just replace your transaction with a higher fee--oh wait. I see.

There are attacks that full RBF introduces, like American call option problem, and now with full RBF you have an imbalance of incentive mechanisms between the two parties between the sender and receiver where the accepted payment amount and BTC/USD trading pair moves against... well, don't trade. So then the argument then is that you have-- it's not even trading, it's just purchases. It's a call option on a purchase you want to make, and htis is supposed to be money. The value of money is different based off of which side of the option you're on, and you're no longer revealing to the other side what kind of contract you're entering into. The best steelman argument I heard was by Antoine Riard in his alternate proposal for how to get to full RBF, which is essentially that-- my position would be that, we should go full RBF because that's how the protocol works anyway. But at the same time, the rules around the mempool created an economy that already exists and by saying well that's an economy based off of false assumptions that we shouldn't have introduced but we did and now we're making it not a policy as developers which to me feels scary. We should be honest that we are making economic policies about what viable businesses are; ... most of us in this room haven't built a business, and they built theirs off of economic models that clearly do work. Antoine says, as developers we should work on special policy rules that work for different use cases on the network rather than to arbiter the class of use-cases in the design of the set of rules.

We have had this debate for over five years at this point.

The rules of the mempool when it comes to replacement can be used to your advantage. As Bitrefill, what if on every 20 minute horizon you aggregate all your inbounds that you spend while they are unconfirmed and then you effectively pin them. The users can certainly try to double spend out from you but it creates a huge cost for them to do that. RBF pinning in that context should work today.

They can still accept zero-conf transactions, even in the RBF regime. They are saying, though, that these changes would make it impossible to continue working that way. Well maybe there's a bit of a Streissand effect too where this discussion continuing forever encourages attackers too...