Atlanta BitDev Socratic Seminar #12 Topics

atlanta-bitdev-socratic-seminar-12.md

Atlanta BitDev Socratic Seminar #12

October 12, 2022 - TAB Conf Edition

Topics

1. LDK signals support for bolt12 [link]
   • LDK merges support for onion messages
   • Onion messages are a precursor to bolt12 offers
   • Step towards deprecating support for bolt11 in favor of offers
   • What do onion messages do?
     • Simple messages sent btwn peers via onion routing (TOR)
     • Can be sent via blinded routes
     • Blinded routes offer more privacy to the recipient
     • Originally purposed for offers
     • OM + PTLC => async LN payments (receiver offline)
     • OM + ? => ?!?!
   • What are Blinded Routes?
     • Recipient (A) constructs “blinded” route to self for use by Sender (B)
     • A selects well-connected node (P) to route through
     • A constructs encrypted blobs for each node on route from A to P leaving the popular node id unencrypted
     • P node effectively becomes bridge between sender/receiver
     • Message destination could be any node within 2 hops of popular node
     • A provides blinded route data to B
     • B finds route to P
     • B constructed encrypted blobs for each node on route to P + blinded route to A (can include invoice)
   • What do offers do?
     • Allow for static invoices
     • Refund functionality: send invoice offer, receiver wallet sends invoice to vendor, vendor pays(e.g. ATM or refund)
     • Receiver privacy (don’t reveal node ID or UTXOs)
     • Subscriptions via offer extensions
   • What are async LN payments?
     • Mobile wallets need to be open in foreground
     • All mobile wallets likely using LSPs
     • OM allows sender LSP to hold payment until recipient LSP sends OM to sender LSP indicating that recipient is online
     • Only locked liquidity is senders
   • What about spam OMs!?
     • Can rate limit peers
     • E.g. few kilobytes of OMs per second
     • Can restrict fwd’d messages to channel peers only
     • Forces attacker to open channels to all nodes they want to DoS – expensive!
2. LND/BTCD bug [link]
   • LND testnet error

   2022-10-09 22:20:06.866 [INF] LTND: Waiting for chain backend to finish sync, start_height=2350195
   2022-10-09 22:20:07.828 [INF] LNWL: Started rescan from block 0000000000000027e44f015d141df1aeff3794ac4b0b7303ca1039c6baa35a4c (height 2350075) for 0 addresses
   2022-10-09 22:20:08.093 [ERR] LNWL: Unable to complete chain rescan: readScript: script witness item is larger than the max allowed size [count 396669, max 11000]
   

   • LND mainnet error

   2022-10-09 21:56:48.549 [ERR] LNWL: Unable to process chain reorg: unable to get block 0000000000000000000400a35a007e223a7fb8a622dc7b5aa5eaace6824291fb: readScript: script witness item is larger than the max allowed size [count 33970, max 11000]
   

   • What happened?

     • Testnet tx [link]
     • Mainnet tx: [link]
     • Tweet [link]

   • Barak's tx has a witness stack that is too large to be parsed

   • What is a witness stack?

     • required data in a stack format used to check transaction validity
     • e.g. scripts and signatures
     • additional reading: https://bitcoin.stackexchange.com/questions/77180/what-is-the-witness-and-what-data-does-it-contain

   • What does "too large" mean?

     • Post segwit introduced concept of block weight
     • Block size limit = 1,000,000 bytes (1 MB)
     • Block weight limit = 4,000,000 vbytes (4 MB)
     • On-chain blocks remain 1MB but virtual segregated witness data provides ability to scale up to 4MB vbyte blocks
     • 1 pre-segwit byte = 4 segwit vbytes
     • Segwit v0 max script size = 10000 vbytes (10 KB)
     • Segwit v1 (Taproot) max script size = implicitly bounded by new block weight limit or 4,000,000 vbytes (4 MB)
     • Defined in BIP-0341 https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_ref-9-0

     Script size limit: The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.[9]
     

     • btcd had a bug!

       • lnd uses btcd wire parsing library to deserialize raw blocks
       • segwit v0 of btcd included a consensus level check for witness size limits of 11000
       • btcd wire parsing layer had same maxWitnessItemSize = 11000 [link]
       • segwit v1 of btcd updated consensus layer to be inline with new 4MB block weight limit
       • wire parsing layer was not updated
       • wire parsing layer check included this limit as a "defense-in-depth" check
       • defense-in-depth?
         • infosec tactic
         • uses layered security controls
         • provides redundancy in case of security control fail or vulnerability
       • aka its a CYA check in case something weird happens -- ironic!

       

   • How did it get fixed?

     • BTCd PR fix: btcsuite/btcd#1896
     • update btcd wire parsing lib to the new weight limit of 4,000,000

   • LND PR fix: lightningnetwork/lnd#7004

     • update go modules to new btcd version

   • LNsploit: https://stacker.news/items/80134 (J)