Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
The bold values are the witness program lengths and address lengths of the segwit v0 programs (BIP-141), which clearly need to be covered in my proposed amendment. 32 bytes is also the proposed witness program length for segwit v1 that would correspond to a taproot (BIP-341) program. On Wed, Jul 15, 2020 at 5:05 PM Greg Sanders wrote: > Can you make it clear what the bold vs not-bold numbers mean? > > On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> >>> That brings me to Matt's point: there is no need to do this right now. >>> We can simply amend BIP173 to only permit length 20 and length 32 (and only >>> length 20 for v0, if you like; but they're so far apart that permitting >>> both shouldn't hurt), for now. Introducing the "new" address format (the >>> one using an improved checksum algorithm) only needs to be there in time >>> for when a non-32-byte-witness-program would come in sight. >>> >> >> As a prerequisite to taproot activation, I was looking into amending >> BIP173 as stated above. However after reviewing >> https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors >> it seems that insertions of 5 characters or more is "safe" in the sense >> that there is low probability of creating a valid checksum by doing so >> randomly. >> >> This means we could safely allow witness programs of lengths *20*, 23, >> 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses >> of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also >> support a set of shorter addresses, but given the lack of entropy in such >> short addresses, it is hard to believe that such witness programs could be >> used to secure anything. I'm not sure what the motivation for allowing >> such short witness programs was, but I'm somewhat inclined to exclude them >> from the segwit address format. >> >> Given that we would only be able to support one of 39 or 40 byte witness >> programs, it is sensible to choose to allow 40 byte witness programs to be >> addressable. This is the maximum witness program size allowed by BIP 141. >> >> So my proposal would be to amend BIP173 in such a way to restrict "bc" >> and "tb" segwit address formats to require witness programs be of size >> *20*, 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes >> (between 2 and 40) would, of course, still be legal in accordance with BIP >> 141; however they would be unaddressable by using this "bc" and "tb" >> prefix. Another address format would be needed to support other witness >> sizes, should the need ever arise. >> >> -- >> Russell O'Connor >> ___ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
Can you make it clear what the bold vs not-bold numbers mean? On Wed, Jul 15, 2020 at 4:56 PM Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> That brings me to Matt's point: there is no need to do this right now. We >> can simply amend BIP173 to only permit length 20 and length 32 (and only >> length 20 for v0, if you like; but they're so far apart that permitting >> both shouldn't hurt), for now. Introducing the "new" address format (the >> one using an improved checksum algorithm) only needs to be there in time >> for when a non-32-byte-witness-program would come in sight. >> > > As a prerequisite to taproot activation, I was looking into amending > BIP173 as stated above. However after reviewing > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors > it seems that insertions of 5 characters or more is "safe" in the sense > that there is low probability of creating a valid checksum by doing so > randomly. > > This means we could safely allow witness programs of lengths *20*, 23, > 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses > of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also > support a set of shorter addresses, but given the lack of entropy in such > short addresses, it is hard to believe that such witness programs could be > used to secure anything. I'm not sure what the motivation for allowing > such short witness programs was, but I'm somewhat inclined to exclude them > from the segwit address format. > > Given that we would only be able to support one of 39 or 40 byte witness > programs, it is sensible to choose to allow 40 byte witness programs to be > addressable. This is the maximum witness program size allowed by BIP 141. > > So my proposal would be to amend BIP173 in such a way to restrict "bc" and > "tb" segwit address formats to require witness programs be of size *20*, > 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2 > and 40) would, of course, still be legal in accordance with BIP 141; > however they would be unaddressable by using this "bc" and "tb" prefix. > Another address format would be needed to support other witness sizes, > should the need ever arise. > > -- > Russell O'Connor > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses
On Wed, Nov 13, 2019 at 1:31 AM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > That brings me to Matt's point: there is no need to do this right now. We > can simply amend BIP173 to only permit length 20 and length 32 (and only > length 20 for v0, if you like; but they're so far apart that permitting > both shouldn't hurt), for now. Introducing the "new" address format (the > one using an improved checksum algorithm) only needs to be there in time > for when a non-32-byte-witness-program would come in sight. > As a prerequisite to taproot activation, I was looking into amending BIP173 as stated above. However after reviewing https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb#detection-of-insertion-errors it seems that insertions of 5 characters or more is "safe" in the sense that there is low probability of creating a valid checksum by doing so randomly. This means we could safely allow witness programs of lengths *20*, 23, 26, 29, *32*, 36, and 40 (or 39). These correspond to Bech32 addresses of length *42*, 47, 52, 57, *62*, 68, and 74 (or 73). We could also support a set of shorter addresses, but given the lack of entropy in such short addresses, it is hard to believe that such witness programs could be used to secure anything. I'm not sure what the motivation for allowing such short witness programs was, but I'm somewhat inclined to exclude them from the segwit address format. Given that we would only be able to support one of 39 or 40 byte witness programs, it is sensible to choose to allow 40 byte witness programs to be addressable. This is the maximum witness program size allowed by BIP 141. So my proposal would be to amend BIP173 in such a way to restrict "bc" and "tb" segwit address formats to require witness programs be of size *20*, 23, 26, 29, *32*, 36, or 40. Witness programs of other sizes (between 2 and 40) would, of course, still be legal in accordance with BIP 141; however they would be unaddressable by using this "bc" and "tb" prefix. Another address format would be needed to support other witness sizes, should the need ever arise. -- Russell O'Connor ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Lightning - Is HTLC vulnerable? And mention of Channel Factories
On Tue, 14 Jul 2020 at 16:42, ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning Mr. Lee, > > > Sorry. Re-sending with correction to CC bitcoin-dev > > > > I am sorry if this was already brought up in previous threads. If I know > > lightning network correctly then HTLC is used to enforce settlements on > > blockchain if there is a dispute. Could a person lose money if their HTLC > > does not get confirmed in the timeframe or if an older HTLC gets > > confirmed first? I see different ways this could happen. > > > > One, if the blockchain is very saturated with other transactions. The > > reason we need lightning network is why it might have troubles with > > settlements? > > This could happen, but the entire exercise is to move transactions off the > blockchain, precisely to lower this risk. > > Otherwise, transfers onchain will take a long time. > In practice, a long time to settle a payment will invalidate many > real-world economic exchanges anyway (consider paying for food at a > restaurant --- if your payments take days to settle, the food has gotten > stale before the restaurant receives payment and releases your food). > Thus, if an onchain transfer takes a long time to settle, there is already > risk of economic loss present. > > By moving activity offchain, we reduce pressure onchain and improve > settlement speeds on both offchain and onchain, reducing risk of economic > loss due to delay. > > > > Two, competition from a different conflicting HTLC. A newer > > HTLC might not get confirmed before an older HTL. > > I cannot make sense of this. > > You cannot create conflicting HTLCs. > Correct. Removing or Creating an HTLC is something that both channel partners need to agree on. They may create multiple pending HTLCs as long as there are enough funds, but creating conflicting HTLCs is not possible. > > > > I found out about a recent attack technique that sounds like it might be > > similar called "flood and loot". > > Roughly, my understanding of Flood and Loot is to make a lot of > uneconomically tiny HTLCs going through a target victim forwarding node. > You make circular routes going from your own node back to yourself. > Then you refuse to actually claim the HTLCs sent back to yourself. > No, the way I understand it is that an attacker, say Malleroy, routes a lot of medium sized HTLC payments from his node to his node via a victim node, say Alice's, and possibly other nodes. Then Malleroy *accepts* the payments by publishing the hash on the receiving end, so he gets all the sent funds on his receiving channel. Malleroy's receiving node behaves completely honestly, and nobody can prove that it belongs to the attacker. Finally when Alice claims her HTLC by presenting the hash, Malleroy just ignores the claim. Now Alice, the victim, is forced to close the channel to prevent the HTLC to timeout. If Malleroy does it with multiple victims at exactly the same time, they will all compete with each other. The victims cannot increase the fee for the HTLC claiming transaction, because they are the ones who force-closed the channel. CPFP doesn't work, because their ultimate output is CLTV'd. As soon as the HTLC timeouts Malleroy can claim the still pending HTLCs using an RBF transaction. So it is Alice who has to force close, which puts her at a big disadvantage. Malleroy will have to pay the lightning fees, but they are negligible. The fee for the on-chain force-close transaction (with the HTLC outputs) is paid by whoever opened the channel. AFAIK the fee for the HTLC resolving transactions is paid by whoever claims the HTLC. In this scenario it is paid from Alice's money. If Malleroy opened the channel, he risks losing some funds to on-chain fees. On the other hand the one who pays the fee controls the fee. He could negotiate a very low fee (say a cent per HTLC), when the network is idle and then wait for a natural congestion before starting the attack, giving him a low risk with high success probability. Every HTLC he can claim after timeout is profit. Regards, Jochen ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
