2022-03-17
Austin Bitcoin Developers
Socratic Seminar 26
https://www.meetup.com/Austin-Bitcoin-Developers/events/283108532/
https://austinbitdevs.com/2022-03-17-socratic-seminar-26
Welcome to Austin BitDevs everyone. The monthly bitcoin conference in the center of the bitcoin capital of the world. Alright. We'd like to usually start this with a little survey to get to know our audience. Not a KYC thing. Feel free to lie, we will not be verifying this information but it's fun to see.
There's going to be a little competition. The person who traveled the furthest to be here is going to receive a gift from Coinkite. To start off, who came from outside of Texas? Raise your hand. Okay. Keep your hand up if you came from outside the US. Alright. We have 3 there. Not Canada. How many is this your first time to the Austin BitDevs socratic seminar? Alright. Welcome, welcome. How many of you is this your first socratic seminar at all ever anywhere in the country?
This is supposed to be a meetup. We don't just lecture and rant at you; it's supposed to be a discussion between all of us. We will bring up some topics, but you can tell us we're stupid or your take on it. It's supposed to be an authentic discussion on bitcoin tech. Someone might say something controversial; please respect their privacy. Don't say you heard someone specific said something at bitdevs. Bitcoin is going to take over the world, so let's not screw someone over with taking photos. We hope to have a little bit of a discussion. If you have a question or something you want to bring up, there's a roaming mic to continue the conversation.
You can go to our website; you can follow along with the links and the discussion topics we're going through. We take our time somewhat, but there's a lot of material so if you want to read into something more and there's links there. There's also a telegram chat and a sphinx chat. It's on the website. All the bitcoiners in Austin coordinate, like with dinner plans. If you can't get into the Unchained Bitcoin Commons, let me know there.
This is the Bitcoin Commons. Unchained Capital has offices in this floor. Bitcoin Commons in this space is a public space supposed to be a bitcoin co-working space. We have Marty Bent's studios over here. We have hosted some workshops from Jimmy Song, and we have been here a few months and we hope to expand on the momentum we already have being the bitcoin capital of the world. We encourage bitcoin events, conversations, events, businesses, just everything bitcoin.
Everyone is hiring right now. If you want a bitcoin job, then go find someone. We have a link to bitcoiner jobs. Unchained Capital is hiring. Raise your hand if your company is hiring. Also the Bitcoin conference in Miami is in a couple of weeks. If you want to attend and don't have a ticket, use code AUS25 for 25% off your ticket and help support bitdevs. Austin Bitdevs.
thebitcoincompany is launching its product right now. They sell gift cards for bitcoin. This is an exclusive announcement, the first public announcement of this product. Go to thebitcoincompany.com and Google Play app will be ready in 10 minutes. It's in the app store, you can download it. Go check it out.
Less happy news... we like to focus mainly on technical conversations and topics, but we don't want to give the impression that as Unchained is hosting this, we don't want to give the impression that we were pushing this under the rug for anyone on twitter or following the bitcoin internet in general. You might have heard this news. I will talk about this briefly, but if you want to ask us questions afterwards we're more than happy to discuss it. Basically we experienced a data leak through one of our third-party service providers. This was a company that helped us with marketing campaigns. There is a lot of problems in their processes that we discovered as a result of this. Basically they were socially engineered to give someone who was not a member of the Unchained team or certainly nobody who should have had access, to give access without verifying their information. It was strictly our marketing platform, so all the PII was not impacted, nothing on our platform, no keys, and another kind of like obviously no leak like this is good or positive but I think this kind of highlights why at Unchained we do everything bitcoin native, multisig first. It's really like you shouldn't have to trust us, and we obviously still have some work to do with locking down this inofrmation. The good news is that it's not llike in other circumstances where-- you still control your keys, your funds are still safe, so it's just marketing information not even addresses or anything like that. That's the story there.
Can I say something? One thing that I would just say on top of that is that... it's serious. It was unfortunate that it happened period particularly this week when we're bringing everyone in to have bitdevs and have Bitcoin Takeover Austin tomorrow. In our world, it's a high severity. Any leaks are unacceptable. We will learn from this and we will be better from it. It's all detailed on our blog on our website. You can read about it, or you can ask about it. Marty and Matt ripped today, I haven't had a chance to listen yet, but I told them to do their worst. We'd like to think that we do good work, and when we make mistakes we own it, so we will learn from this and we will be better. If you guys have questions, come find me and talk with me later. This was a tough one to stomach, but we'll do better. As we get into the rest of the program, the sound in here does carry. We're going to go through a lot of technical discussions. We will have a floating mic, but please don't have conversations in the back because those are easily heard at the front. This night is about learning about the technical developments of bitcoin which is hard if people are talking on the side.
What should current customers of Unchained who may have been impacted by this look out for going forward? Realistically the most immediate thing to look out for is spear-phishing attacks. There is now an association between Unchained email addresses and Unchained. As part of this leaks, there was also accounts access. So spearphishes would look like direct emails telling you to do this, enter your password, or enter your seedphrase. One, you should never enter your seedphrase into anything, but when people have access to associations between emails and companies those are the principle type of attacks we saw with the Ledger leak. They started making assumptions about other services the same users may have been using as well. It's important to be on high alert about this. We do have links for this in the blog post which was part of the release of this about what to look out for.
One more thing. On a higher note, I want to thank all the partners from the Bitcoin Commons. We don't have official sponsors of Austin BitDevs, but we do have sponsors for Bitcoin Commons including NYDIG, Swan, Spiral, Braiiins, Satoshi Labs, Priority Power, Trammell Ventures. I wanted to make that shout out.
Just a heads up, as Parker was hinting at, we don't talk price here. We avoid a lot of newsy items. We really just want to dig into the technical things happening in bitcoin. I think there's often a misrepresentation of bitcoin being this oh all the fun interesting tech stuff is happening elsewhere, but that's only because people aren't paying attention. We want to spread this information and make people aware; we hope you will see this in the conversations. Please feel free to ask questions about anything you're not clear about. There's a lot going on and a lot to keep track of.
As we go into Miami for Bitcoin 2022, I think on Tuesday April 5th at 3:45pm in the afternoon. We're doing a couple different cities doing a joint event. New York which started this event, then us, and then Miami. It would be cool if all of you who are in town for Miami could show up and represent us.
Hello everyone, I'm representing Base58. We're the world's best bitcoin education company. We have our flagship product which is a 6 week bitcoin transaction protocol course taught remote by my co-founder and partner at Blockstream. We're opening up registrations pretty soon. If you're interested, find me after bitdevs please. Thank you. They are based out of Houston which is the second best bitcoin city in the world.
We will be wrapping this up between 830 and 9, and bbq will start coming in here. We will shift festivities and general bitcoin enjoyment to other venues by 10pm. Please don't start talking before we move on to that.
In you're in Austin, there is a hackathon this weekend called Sats by Southwest thing. I wanted to highlight some of the cool projects that were built. Who here attended the hackathon? Who wants to come up and talk about their project.
Howdy. One of the projects that I was excited to work on, I was a mentor there providing guidance, but I was working on something called whisper addresses which is a re-creation of Stealth Addresses. At the hackathon, I worked on this protocol called whisper addresses which is similar to bip47 stealth addresses. In this protocol in bip47 and in mine, you want to send bitcoin to someone privately so you get a public key from them that you tweak. They post a public key on a website, you tweak it, you send money to the tweaked address, and then you send them the tweak so that they can recover that money and add it to their private key. With whisper addresses, you send it in an email instead of how it's done in bip47. I think it's cool to build privacy tech for bitcoin and this is an attempt of mine to make something.
I was at the hackathon this last week and I teamed up with some people from Atlanta Bitdevs. We made a project called pleb.fm which is a website we built in 24 hours. It's a bitcoin-lightning jukebox. You can search for whatever song you want, you can bid your sats on the next preference and the highest bid is the next one in the queue. It was just a fun cool app. The two ladies serving drinks in the back, we just got them on lightning so please be sure to tip them in lightning.
I was also at this hackathon this weekend. I worked on a project that I call spadz-- spontaneous ads on lightning. You can push payments to people and include metadata with those payments, like keysend is the name for that. Basically you can push a payment to someone and include some information about an ad, like an image or text, or build a reader to show that in real-time. The idea is basically you can get paid to receive ads as ads get pushed away from being in the middle of your feeds, they might still go somewhere else. I'm not on Facebook anymore, but I miss the targeted ads which were pretty good and did discovery for me. I think there's value there. Maybe it will kind of instead of Facebook getting paid to reach you, maybe you will get paid to get reached yourself instead.
There was another project. For the last 2 years, we have heard him talking about DLCs. At the beginning, it was a totally abstract idea. During the hackathon, we worked on an SDK so that a mobile developer who doesn't know anything about DLCs could do peer-to-peer bets on mobile with DLCs like a peer-to-peer sports book on bitcoin, and you wouldn't have to understand how it works under the hood. This was a topic that was pure research when the meetups started, and now we're going to be close to an actual SDK to build apps on it. It's cool to watch the progress of these ideas. We still don't understand how it works.
There were a lot of cool projects. You can view it on the website and read about the other projects.
There's some more bad news. Wasabi Wallet was one of the main privacy wallets. Sadly they have gone a different way. In the past, Samurai would FUD them about vairous stuff, but recently they announced they will start censoring transactions in their coinjoins because of regulatory issues. It's kind of sad to see. This company was founded by 2 lawyers, so it makes a little bit of sense. Enough said. They are out of Hungary. They announced they are going to start doing this; the company zkSNACKs that created Wasabi is doing this, so someone could run their own Wasabi coordinator, but you will have to go into your config file and type in a new onion address and my mom won't be able to do that. What does your mom have to hide? Exactly. Wasabi wants the privacy, but zkSNACKs doesn't want illicit activity. QuadrigaCX went through it. The Bitfinex hacker went through there. The twitter hacker too. The big one in China the latest ponzi scheme went through there. So basically everything went through there, so they got a lot of legal pressure, it's sad to see. I wouldn't recommend using Wasabi. You should use Bitcoin Core instead. If you want to coinjoin, use joinmarket. Joinmarket doesn't have a coordinator. Oh, you can use another Wasabi coordinator. There is a Chaincase coordinator but we'll see how long that lasts. There are also some other privacy strategies coming. I think we have another Wasabi topic coming up.
There was an address reuse bug in Wasabi. Another Wasabi sad topic. This was a few weeks ago. Someone was- who was the hacker? Maybe it was the Bitfinex hacker? They went through Wasabi to try to get some anonymity, and their change output and their mix output went to the same address so they were able to coordinate that and arrest the individuals. I heard about this and I went through the code and found the issue. How it happened, basically, is that the user was running 2 clients of Wasabi at the same time so that they would have two UTXOs instead of one. When you generate addresses for mix output and change output, they both used the change output derivation path. They were using the same seed, two instances of the wallet. Both wallets generated addresses, one picked it as a change address, one picked it as a mixed output. I tried to report the bug, but sadly they didn't do much about it. This is another sad thing to see happen to Wasabi.
How would you mitigate this? The way their wallet is architected, it's all built on top of a json file they write into. If they had an sqlite database with locks, they could avoid that. They could have also different paths for change and mixes.
nopara one of the Wasabi devs had a comment.. it was put out originally that Coinjoin was cracked but really this was more of an implementation bug than a problem with the coinjoin protocol itslef. Coinjoin isn't broken, just Wasabi. Moving on, that was sad.
This is a cool proposal by gleb and Antoine Riard. They found like half of the vulnerabilities in Lightning. They are really smart. They have a new protocol called coinpool where you have a single utxo shared by a bunch of people. You could also make lightning payments, and trade within it, and do all this fancy stuff. They detail what it would take to get in, and it requires ANYPREVOUT plus two more opcodes. It would be a couple soft-forks to get this to be doable or one big soft-fork. The way they talk about it is pretty cool, they said they think for 7.9 billion people on earth we all want them on bitcoin. With a 1000 sized coinpool instances, everyone could get access within 6 months of block space. This is one way of batching it together and everyone can share a single utxo instead of having 7 billion separate utxos. Not just in lightning, but imagine if there was a run on Coinbase or some big exhcange and everyone wanted to get all their coins out. You're going to need many blocks, and then it will fill up, so you need to have more control over a single utxo on to many people and that's really an important strategy. We're going to need something. There are several different pieces that we need that help solve this in different ways.
What about the interaction necessary for other people in the pool to use that? What about when they want to get in and out? Does everyone have to be online and approve it? That is the problem. If you have 1000 participants, and someone wnats to transact, then everyone needs to sign it. If one guy is out in the middle of the forest or his phone is dead, then you have to do something else like closing it out on-chain. There might be another protocol that can solve this. There's also problems related to not just... when you're doing the eviction, the eviction is the important one because of how much chainspace it takes up. Merkle trees are nice for compressing data, but as soon as you need to reveal something you need to reveal a large merkle inclusion proof which can take up space and be expensive. OP_EVICT is one way to solve this, a proposed solution for mitigating that. I saw a hand in the back?
I haven't actually read this, but does anyone know about coinpools as a pre-req of everyone getting into this, to pre-sign the cartesian product of all the exit scenarios with ANYPREVOUT for the people in it so that they can get out whenever they want? The problem is that if I send $5 to Bob then we all need to re-do that because the channel updates to change that. There are similar solutions with OP_CTV where you don't have to sign. You can commit to a transaction that has the state of being able to leave and come out, but you still have chainspace problems and these updating the state problems. I think there's a solution involving watchtowers so that you can use adaptor signatures, not reveal information but you can have watchtowers that can watch for changes and that can help with being online type of issue. In the coinpool email, they gave an example of 1000 people in a coinpool. But if it was just me and my friends, like 5 people, then I'm not going to close it out on my friends really. Spacechains and Chaumian e-mint, it's mostly good for situations for groups you're with. You can imagine church groups where they are sharing a single UTXO and you can optimize the processes around that, and take it off-chain. Similar to lightning where you only use the blockchain as an enforcement mechanism.
I thought we could get channel factories with just one of those opcodes? It is similar to channel factories, plus more cool stuff. They go deeper into that in the email. Channel factories, we don't have great solutions for channel factories yet because there are issues like how do you deal with evictions, enforcement, and online state updates. OP_EVICT came from thinking about channel factories specifically.
What's the chance that those opcodes will get into Bitcoin in the next 5 years? Maybe ANYPREVOUT but the other ones I'm pretty bearish on. Bitcoin is a hard system to change. It took us 4 years for taproot and everyone likes taproot. I think the things that are proposed just a month ago, it will be a while. There's a bikeshedding problem, taproot nobody understood, but the simpler the opcodes get the more controversy there is. Setup a DLC on when they get in... sure. Might need other opcodes to make that more efficient on the different conditions.
On lightning channels, it would take 18 years with multiple 2-of-2 lightning channels to get everyone on board, if we all opened up channels individually. It's not even just onboarding. Lightning today works through penalties, and penalties work through timelocks. If everyone wants to leave at the same time, and you can essentially DoS the lightning closures if enough people are going out at the same time. You can prevent people from getting their penalty transaction in before the timelock ends which is a much bigger danger. We can gradually onboard people into lightning. Once we get everyone on, you undermine the entire incentive mechanism if the penalties have any chance of maybe being not enforceable.
Mimblewimble
We get to make fun of shitcoins a little .If you haven't heard of mimblewimble, it's one of those privacy protocol blockchain things. Grin and Beam are two of the main ones that have implemented one. Someone found a way to DoS attack the transaction propagation. You can prevent transactions form ending up in the blockchain. The way mimblewimble works, ... I can just add two transactions together, and it reduces space, and then you only see a single aggregate one. The way to do this is to just double spending in the mempool. I can add my same transaction, and only one of these are valid. You just do that over and over again with every mempool transaction so that only a few can get in. They discuss ways of mitigating this, but they weren't really mitigations, it was like just get more connections and validate more stuff. It wasn't really a solveable problem which is kind of sad. This vulnerability there's two pieces of it; the dandelion transaction propagation and then mimblewimble which were originally proposals by bitcoin developers. These are really hard things to design. Let's say it was championed by bitcoiners, rather.
Is litecoin still deploying mimblewimble? They did not do it. Okay. Smart developers over there. Well, no developers over there. Okay.
DLCs again
Chris from suredbits made a cool email. Who here knows about DLCs? Alright, we're improving. If you don't know, DLC stands for discrete log contracts. I used to work on this. It lets you make bitcoin bets. It's 2-of-2 multisig, there's an oracle, and you can spend from the multisig with a singature from the oracle deciding the outcome. That's kind of the elevator pitch of it. Chris proposed a way to do it but instead of making bets, you do it for recurring payments. His example is that you have a $20 netflix subscription and instead of paying $20 each month, you can setup a DLC with them solely funded by you and at the end of the month they have permission to claim just those $20 from you. On lightning, this would be inexpensive and they would slowly get money from you each month without having to have pre-authentication to take money from you. Doing it on chain wouldn't be that bad at the moment either. We were talking about this earlier, and it kind of just explains what a PTLC is. It uses an adaptor signature on a UTXO. It's a little bit of an over-complication but it's cool to think about different creative ways to use DLCs other than just gambling and hedging.
One of the cool things that this proposal highlights is that the best proposal that you want like when it's hard to upgrade bitcoin is that you want building blocks. You want things upon which you cna build other things. It's easiest to explain DLCs in the context of bets, but it's really a protocol for having basically untrusted trustless oracles that you don't have to trust really. Well, you kind of do. You can split up the risk, they don't have to know about you and your bet, and that helps mitigate the trust issues. This is really about oracles and what that means is that you can build other tstuff on top of it. For recurring payments, it's similar. The netflix subscription example- Netflix is being the oracle that would satisfy the transaction. You put together a bunch of transactions, so you would have $20/month and give it to Netflix ahead of time. You would do that using the adaptor signature from Netflix, and then Netflix each month would redeem that pre-prepared transaction .Alice would be able to do this unilaterally without having to interact with the oracle. Netflix can just take that and redeem that when they are ready, and Alice can also spend that UTXO before Netflix redeems it, effectively canceling the subscription. DLCs allow you to create other protoocls, make neat interactions, and do it today with the tools today. Look at the suredbits website for DLC stuff; it was originally proposed by Tadge Dryja but suredbits has built out a lot of tooling for this and taking on the mantle for DLCs. There are also some good blog posts about taproot.
What does the oracle broadcast in that scenario? The time? It's the end of the month-- so the oracle is a clock? They can also broadcast like Netflix could turn off this week, so you pay them and then by the way we don't have a business, no more service. They would broadcast that publicly.
In order for this to work, I have to pre-deposit bitcoin? Well, yes and no. It's still your bitcoin. You can take it out at any time. You will have a specialized wallet for subscriptions and you would label your coins for this. You would label your UTXOs that are set aside for this. You can easily keep track of your subscriptions with something like this and hold services accountable. You would have a specialized wallet that would keep track of these things, you would sign them with an adaptor signatur,e and then send them off to the service.
Can the amount change? You can have a price oracle as well. Lightning subscriptions would be cool for this. Maybe house payments or something like that because it's on-chain. It could also be on lightning theoretically. When you have multiple oracles and combinations of oracles, does it make the onchain footprint of DLCs bigger? No, it's the same, it's just off-chain data.
Someone is asking, what changed in the past year? I don't think eanything. I think we just got smarter. So now we know how to do subscriptions with DLCs.
Can this be used with option contracts? Yes. Someone here has a company that does this with DLCs. Go find him and talk to him, yeah.
To Bryan's point... something we talked about last month is that Jeremy Rubin.. no not him.. it was Lloyd.. proposed a way to do DLCs with CTV. Right now we do adaptor signatures and fancy math, and then you have a signature for every single possible outcome, you need to verify them and store them. It could be multiple megabytes of data and it takes time and space to handle these. CTV ... the outcomes are pre-committed in the CTV tree. For the uninitiated, CTV is another opcode proposal so this is not yet possible on bitcoin at the moment. CTV is OP_CHECKTEMPLATEVERIFY which is a proposal where it is one of the current proposals for doing covenants where you pre-commit to spending output. So currently we only have ways to lock your inputs according to certain conditions, and covenants lock in how you are allowed to spend the UTXO and this idea can be used to make more efficient DLC contracts.
Jeremy Rubin made a programming language called sapio which is a way to easily make OP_CTV contracts and non-CTV contracts. He posted this to the mailing list. It's 201 lines of code basically to do DLCs with CTV. If you can't read rust, then you can't read this, but it's pretty simple and really interesting to see this being built in a weekend to do CTV DLCs. Do you model it with 100,000 oracles or 100,000 possible outcomes? One oracle, 100k possible outcomes, and possible to do it on a personal computer in 13 seconds. It would take a lot longer to do that with current DLCs constructions. He was DMing me saying we have CTV signet so you can start doing it if you want.. if you want to start playing around with it then you can.
What's the consensus of the CTV opcode getting merged? Who thinks CTV should be merged ineventually? About the same number of people who know what CTV is. Who thinks it could be in the next 2 years? Okay. It's possible we have seen our last soft-fork. It's messy out there.
Teleport transactions
If you're a Wasabi refugee and you need some privacy for UTXOs, Chris Belcher has got you handled. He has been working on an implementation of coinswap called teleport transactions which is a way of swapping UTXOs with people in completely separate transactions. This is for gaining privacy. We would spend to this multisig that we each own, and then if we comply we swap UTXOs to each other and then we each have 1 BTC but it was the other person's bitcoin. So if mine was from a darknet market, and the other one was from Coinbase, then they don't know what happened to it here. He can also do it with routed coinswaps so that you can have huge teleportation of UTXOs and it all goes everywhere. It's pretty cool. He released the alpha version of it. It took a lot of work. In the README he has a huge list of everything he still wants to do with it.
So you can form a coinswap network? Maybe. This is more of a protocol, and then you would build stuff on top of it. It's kind of like lightning in the sense that, with lightning you can have a channel, we could open up a channel, have off-chain transactions, scale that and have some routing. You need a little bit more of a -- the discovery mechanisms are a little bit different. It uses mechanisms similar to submarine swaps to get this to work. It's more of a protocol to find a partner to mix your outputs with basically.
How much interaction is required before Alice and Bob? Do they need interaction? I think it's a few rounds. While we're looking at this, this is from the creator of joinmarket. It's exciting. That's a real project that lasted a long time and didn't break. I'd assume it's multiple round trips because they have to negotiate addresses and then give each other signatures.
What happens if you swap with some hacker's coins? You're out of luck. You want to swap with someone else. Part of the idea behind this actually is about creating deniability. Even people that don't use this protocol are made more secure yb this protocol because it breaks the current heuristics that the Chainalysis companies use to say that one output is probably change etc. As soon as more people do something like this, you have a bit of a free-rider problem because everyone starts to benefit.
This is really good for shopping carts. You can have btcpayserver swapping with the customers. So now you have this pile that gets swapped between people who are doing non-illegal business and it creates a lot of noise for Chainalysis. You can do a payjoin inside of it, that's a really smart idea.
In general, it seems like the Chainalysis companies have the upper hand. It's a battle between them and privacy having the upper hand. There's no opcode in this proposal. A lot of predictions tonight. It's like a sliding scale, what's your threat model? What are you trying to do? how good are you at using this software? If you are really good at coinjoin, you can get by. But if you make any mistakes, it gets easier to catch you with Chainalysis. It's about making the tools more anonymous. Again, the deniability aspect is really important. On lightning, what you can know, we know what the lightning transactions are and even if we had PTLCs for lightning today, because nobody else is using taproot then that reduces the anonymity you can gain from that and they have the upper hand because nobody cares about privacy but when more people who aren't doing illicit activites care about privacy then everyone benefits from that and that's how you get ahead of Chainalysis companies. If you're sending to yourself, like transactions, right, like Paul Sztorc had a proposal for a deniability wallet where you break these heuristics. This is just one more way to break the heuristics; the problem is that generally we're not using any of these techniques at all. Privacy is hard.
Is this something just general wallets can implement soon and maybe certain bitcoin native companies could do that at some point? It could be. The hard part about this is basically the negotiation protocol and adaptor signatures. Both are doable. Hopefully this becomes an sdk where you can import it and you're good to go, like bdk sdk or something. Just import it and now you can use teleport transactions. We're far away from that, but it is possible.
Real pleb question here. What's the difference between teleport transactions and coinjoin? I hear you guys using this interchangeably. In terms of KYC, because addresses are addresses and if you really want to find out who someone is-- just ask the truckers in Canada, they all got doxxed big time or at least the people donating to them. How can you use this to prevent that? I genuinely ask this from the point of, how does this benefit to not be a retarded money launderer but really because there are people who are genuinely nefarious out there who want to use this to do bad things and I'm sure there will be. Well, this doesn't require KYC. This is just a protocol that can anyone can implement. You don't need a central coordinator. Coinjoins essentially require a coordinator to create these transactions and mix them. But teleportation is different because you can do that peer-to-peer which is the main difference. In coinjoin, we all make a single transaction together and then we spend out to our own addresses. When someone looks at it, they can look at the inputs and the outputs, it's literally money laundering really. But with this, we can swap BTC UTXOs without anyone else being able to see that it happened.
With a lot of the privacy leaks now, it's not like they know for sure. If you spend from an exchange, then they know, which is what happened with donations to the truckers. Chainalysis has heuristics and they can make best guesses about who were involved and you want to reduce the probability that they were right. The more that other people start using these privacy mitigation techniques, the more you can improve the privacy.
Why is privacy important? In the grand scheme of things, the whole point of the transaction is to be transparent. How much money do you have? That's why it's important. Why is privacy important? The point is that it's not important until it is. Once it's important, you can't backtrack. You should be able to leak information on your own terms, and you shouldn't have to expose people who didn't opt into that. We leak information about ourselves all the time, but we chose to do that today, and some people in this room would choose not to do that. Maybe some people in Austin would like to come here to Bitdevs but they don't want to.
I realize I'm in a room here of bitcoin maximalists. I want to open a contrarian debate. If you're starting from a place of privacy, it sounds like you're making the argument for a true privacy coin like mimblewimble. I think it's a legitimate concern to express. We shouldn't be okay... let me re-phrase the question in a more bitcoin friendly way for the room. Should we be okay with the state of bitcoin today? Absolutely not. When I say start from a place of privacy, it's for your own personal chain of transactions. One of the problems iwth many of the privacy protocols is that you lose the auditability of the total block supply or coin supply rather. So you actually want transparency in some places; there are other tradeoffs as well. We want to break the linkages while keeping a lot of the other features. There's a chance that if we do this right then when you break that link you can start from a place of privacy.
Submarine swaps already do that. I don't want to hear about shitcoins.
We need to start using the tools that are already out there, a lot more.
Someone corrected me on the bitcoin-dev mailing list recently when I talked about the tradeoffs between auditability, privacy, and someone corrected me and said well you can't have computational privacy and unconditional soundness at the same time which still means it's auditable even though you get pretty solid privacy. There's a tradeoff between computational privacy and auditability; there are tradeoffs, in engineering especially.
zcash originally forked from bitcoin. Had they forked before the bug was introduced, you could've never 100% proven that this wasn't exploited but we were able to prove with 100% certainty that it was never exploited in bitcoin. That bug... had the miner printed it, all the other versions of bitcoin would have rejected that block so there would have been a chainsplit. You couldn't have printed it and gotten away with it.
With cryptonote, you had a supply issue. It's not a hypothetical. Bytecoin has an unknown supply for that reason.
Zerohedge a few hours ago came out with an article about congress talking about how bitcoin is not a threat to money laundering. Bitcoin is early right now. If we had full privacy in bitcoin, it would be a threat for money laundering in the US.
"“You don’t need privacy” and “privacy is only for criminals” are lies criminals tell you to make their job easier."
Privacy makes money more valuable.
Safer custody with CTV vaults
This is our section on general contract proposals. Some of these are proposals that are not yet in, largely they are all hypothetical. It's hard to do secure vaulting today. Vaulting is a technique for putting constraints around how bitcoin can be spent. The least secure thing is to have single sig, if you lose access to that you lose all your bitcoin. Next up is bitcoin multisig where you're in a quorum. If you want more security than multisig, and without sacrificing convenience; this is a proposal from jamesob it's actually based off of Bryan Bishop's original proposal for doing this. A lot of the proposals today are based on pre-signed transactions. Ideally you want to burn the key you signed with, otherwise you can break the protocol. The simple version of how this protocol works is that essentially you lock up the UTXOs, and what you say is that you would have two spending paths. You lock this in ahead of time where if you ever want to have access to your funds, there's a timelock ATM analogy where you want this to be able to spend 10% of the funds in this vault into the hot wallet and maybe the rest go back into the vault.
Is the vault a separate wallet? What is a wallet? What is the meaning of life?
For CTV, it has to be an intermediate wallet because there's a footgun where if you send the wrong amount into your CTV wallet vault then you can never redeem it because the script requires you to have a specific transaction so you must have a situation where you have this intermediate core wallet vault where you send it from another wallet that knows about it and knows how to construct it correctly. It depends on how you define wallet.. like wallet software, yes. But if the wallet is the seeds, you can have the same seed in another wallet that doesn't understand it as you have in the vault wallet.
re-vault uses pre-signed transactions and watchtowers to get around this. There are tradeoffs- security, convenience, and jamesob's version/CTV of course uses OP_CTV which requires a new opcode.
OP_EVICT: An alternative to OP_TAPLEAFUPDATEVERIFY
OP_TAPLEAFUPDATEVERIFY is another CTV competitor proposal, a way to do covenants, and it's taproot specific. People highlighted a problem with it where basically if you have some amount of interaction in your protocol like 3-of-3 and someone is offline so not everyone can send money, then you have to go on-chain... So it requires O(log(n)) tree structure which is expensive.
ZmnScpXj made a proposal called OP_EVICT and if you were in a channel factory, you can kick out one of the members to just keep going. It could work for lightning channels, coinpool, etc. The idea is that instead of just having pre-signed transactions you have pre-commitments to transactions that could spend out of the coin pool, and then you get signatures from that. Thta's probably the highest level explanation I can give.
I think OP_EVICT makes it easier for those users to re-join as well? One of the things funny about this is that, my guess, I can't put any words in Zeeman's mouth, ubt my guess is that this was proposed tongue-in-cheek because TLUV lets you do it for this one purpose but then it turns out maybe there's a better way to do this one purpose, maybe we should do EVICT instead, or maybe there's another way to do one better way. OP_TXHASH can simulate this method as well. We're in a stalemate where most people agree that we want some of this new functionality, and everyone is proposing new ways, and now we're not getting any new functionality at all. Maybe bitcoin ends up ossifying not because we want ossification but because everyone wants to improve bitcoin in different ways. OP_EVICT is a cool and useful proposal, and ZmnScpXj might say there's no chance of it getting in because he goes on to propose another opcode OP_FOLD.
As someone not reading this drama, is there a vibe that there is some core principle and if we keep coming up with ideas we'll reach perfection? Or is it lots of cooks in the kitchen and it's getting messier? Does it feel like progress right now? Or is it splintering? I think this post was to show that this could be splintered ad-infanatum. It's an infinitely recursive proposal. I think it's funny and clever. It depends on who you talk to. There might be some developers saying we're moving in the right direction and we're optimizing towards something good, but I don't think that. Hopefully people will get sick, too many cooks in the kitchen. Now that we have segwit and taproot, we have a lot more space to introduce new opcodes and advance the scripting. Getting community support is pretty hard. If it's going to happen, it's going to be one of those two.
Even just a year ago, we were uncertain about covenants but now I feel there's consensus that covenants are going to happen but now the debate is only about which opcode is going to enable this and which way is best. I don't think anyone knows about OP_CTV and there's like 5 ways to do it. Simplicity has been 5 years away forever.
In the TXHASH discussion last month, TXHASH was a similar proposal where we could do anyprevout and CTV stuff and people were like, well, it would take 2 years before this gets mature... maybe better to just wait for Simplicity? But then you don't get anything for quite a while. Welcome to bitcoin development.
ldk: Add support for phantom node payments
This is a way if you have a lightning node, a lot of businesses have child subnodes under their main lightning node for accounting and so that your channeldb doesn't blow up. You always have to create infrastructure for this. But LDK added something where you can spin off a private node, accept an invoice, and then disappear. That's kind of the concept. Does it improve privacy? Not really.
It's a pretty cool concept. You can have multiple nodes essentially. If you want to receive a payment, you need to be online. Maybe an enterprise customer, they need to have redundancy. They can't rely on every one of their nodes always being online. They have a shared secret between all their nodes which is the recipient of the payment. The routes and all the other nodes as the first hop, and the second hop is the phantom node which doesn't exist. Each of the nodes, since they have a shared secret, they can decrypt the last onion hop when they receive the HTLC and thus claim it. The drawback is that you can't do multi-path payments because there's no coordination. It's better for small amounts.
Bitfinex has two lightning nodes. If they were using this, then instead of a 50/50 chance of which lightning node to generate from, then it could generate from this and it would happen automatically.
Do any of the other implementations support this? lnd can do this with HTLC interceptors. You have to do your own custom work to do it. They have an Uncle Jim type of construction or something.
Most custodial wallets have arrived at this same solution because a lot of people sort of assume pubkey in lightning is one person's identity, so it's not really useful if you have all these services where you paid with this pubkey or youhave access to some resource on the internet if a hundred people are using that same node. So the nice thing is that this is a single implementation instead of everyone doing their own version.
bdk-cli v0.4.0 release
There were a few interesting changes-- there is a command for proof-of-reserves. We have some BDK people here. BDK is pretty cool. Nothing much to ad.
HWI: support bitcoin app 2.0
HWI is a library that a lot of apps use to talk with hardware wallets. Wasabi uses this. Bitcoin Core uses this. I think a few more wallets use it. Ledger added support for PSBTv2 and descriptors(ish), and signing taproot inputs.
PSBTv2 is a cool proposal. When you create a PSBT today, you propose a transaction and add data. It's not really about negotiating a transaction where one person adds an input and another does the same. PSBTv2 introduces this. PSBT == partially signed bitcoin transaction.
Ledger for a while was always the laggard on implementing things. It's going to be interesting if they start leading the group. In the past, they were behind on updating to the latest bitcoin upgrades and now they are adding it all at once. We talked about this a few months ago, their ledger v2 app and they came up with some clever ways to have this functionality that you get from stateful wallets like checking that you're part of a multisig coordinator. Ledger has a token exchange protocol, they have a low memory Ledger version.
Another cool aspect of HWI is that achow101 has discovered that whenever he adds a new hardware device or protocol, he has to write tests, and it's good that they are all using the same standard test data and in the same sane and expected ways.
Migrate legacy wallets to descriptor wallets
There was a good discussion in the bitcoin pr review group about migrating legacy wallets to descriptor wallets. The wallets would generate a random private key, make a pool, and then move on. Then they added HD paths to make this a little better. Descriptors let you do this where you can say which derivation path you're using with which exact script. For a single sig wallet, it's obvious. But with multisig, there might be timelocks or other things. Descriptors let you write it out and it's pretty simple and now Bitcoin Core is moving over to this. This is a pull reques tto migrate a legacy wallet to this nice descriptor wallet. It goes into a lot that they have to do, like create a descriptor from a legacy wallet, and moving the datasets over, and it was an interesting discussion. Anyone have anything else to add on that?
....
Sensei
There are two development kits for making ... BDK and LDK, libraries written in rust for building bitcoin stuff. They are sponsored by Square or Spiral. Recently there has been a grant to integrate BDK and LDK. One is developed in slack, one is developed in discord. lnd has an on-chain bitcoin wallet and then you lock that up into channels and now it's lightning. Sensei is a lightning node implementation based on BDK and LDK so the on-chain stuff is managed by BDK, the lightning stuff is managed by LDK, then there's lots of glue logic, and then a web UI. The big hook with sensei is really easy child nodes. Sensei is the master training the child nodes, they can be an Uncle Jim and you don't have to spin up a whole node for each child. A child node is basically everything you need to know to sign transactions and open up channels as a child, but things like the blockstate and the gossip, routing, a lot of the resources can be shared. That's what Sensei does. That's my explanation. It's usable today if you fork the github and run it yourself. It's in a wreckless stage, not everyone should deploy it. This could be an app running on your umbrel so you could just point to the blockchain that Umbrel knows about, and then you can run child nodes with Sensei which is also on lightning.
It says enterprise ready on the tin. So ship it. Great.