Joseph Poon [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-04-26 to 2017-04-06
💬 Posted a total of 61 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev, BIP-draft, Lightning-dev, RFC, BOLT Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8

Profile Code

nprofile1qqsvedxvslz9td60awhwty5ul5rjvssm9m4xftftzezqk68gcapnyyg2edftj

Author Public Key

npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8

Show more details

Last Notes

2023-06-09 12:46:38

- reply

📅 Original date posted:2016-08-12
📝 Original message:
Hi Rusty,
Yeah, interesting thoughts!
On Fri, Aug 12, 2016 at 01:17:52PM +0930, Rusty Russell wrote:
> I still don't understand why use an HMAC-of-tx instead of just the txid?
> What does it gain?
I'm presuming you need to index by txid to see if there needs to be a
penalty transaction broadcast, so you can't use that as a secret key.
--
Joseph Poon

2023-06-09 12:46:37

- reply

📅 Original date posted:2016-08-12
📝 Original message:
On Fri, Aug 12, 2016 at 12:54:52PM +0930, Rusty Russell wrote:
> Yeah, I do that already. We give the N+1th hash when we send the
> revocation for N:
>
> // Complete the update.
> message update_revocation {
> // Hash preimage which revokes old commitment tx.
> required sha256_hash revocation_preimage = 1;
> // Revocation hash for my next commit transaction
> required sha256_hash next_revocation_hash = 2;
> }
Yeah, the way I described would (optimally over-the-wire) be a tree of
chained preimages *AND* hashes as a part of the tree itself (so the
chain looks like preimage->hash->preimage->hash instead of
preimage->preimage). That way if you're willing to forgo the ability to
have multiple "next revocation hashes" in-flight (by instead having
multiple trees to achieve multiple in-flight), it's possible to only
send the "next revocation hash", which will automatically reveal the
prior "revocation preimage". In other words, the wire message could only
be sending next_revocation_hash. If one were to use pubkey revocations,
then that construction *requires* using privkeys+pubkeys instead of
preimages+hashes, which ups the cost/complexity -- which is why I said
it probably wasn't worth it.
> Yeah, agreed. Hash trees are nice and simple, so unless we get a
> signficiant win, let's stick with that?
For sure.
--
Joseph Poon

2023-06-09 12:46:37

- reply

📅 Original date posted:2016-08-11
📝 Original message:
On Wed, Aug 10, 2016 at 11:33:46AM +0930, Rusty Russell wrote:
> Unfortunately, watcher knows revocation preimage N, so it can figure out
> some or all previous revocation preimages (and thus hashes).
If you take the results then HMAC it as the final step in
shachain/elkrem (to establish a single leaf), should be fine even if
revocation hashes are used in lieu of a revocation pubkey.
> But it rests on the assumption that there are no unknown malleability
> issues on signatures, which I believe makes crypto people nervous. I've
> asked some, though, as that's above my pay grade!
>
> It also assumes they can't set up the witness such that our sig is not
> 2nd or 3rd in the witness element. I think that's true...
Yeah, good point. Perhaps it could be better to keep it simple and just
use an HMAC of the non-witness transaction. There shouldn't be stuff
that's easily mutatable, and the exposure is not expanded (since that
would break LN's child transactions anyway).
--
Joseph Poon

2023-06-09 12:46:36

- reply

📅 Original date posted:2016-08-11
📝 Original message:
On Thu, Aug 11, 2016 at 11:25:36AM +0930, Rusty Russell wrote:
> Tadge Dryja <tadge at lightning.network> writes:
> > The method of using a revocation key is compatible with shachain/elkrem so
> > has log(n) storage; I'll describe what I developed which omits hashing in
> > the commit script and uses only signature verification. If Laolu has made
> > a different key revocation scheme I'm not aware, but please do post if so.
>
> Oh, I blamed Laolu because he told me about it; sorry for misattribution.
I came up with it a long time ago, and worked out the
details/optimizations /w Laolu more recently (I think he told you that
night when everything was finalized). I mentioned the general
construction to you a LONG time ago too when you were in the Bay Area,
but I probably didn't explain it properly (I was comparing with
Vanitygen, if that helps). I think Tadge was the first to implement it
though, not sure.
> The property I was *hoping* for was the ability for Alice (and Bob) to
> independently predict each others' future revocation hashes/pubkeys.
> That would neatly allow an arbitrary number of commitment transactions
> in flight each way at once. Naively, seems like that should be
> possible.
I'm not inclined to think an increase in complexity is helpful (if this
is necessary), but there are probably some things you can do if you're
looking down these paths.
It's possible to get the same *bandwidth* optimization you want, except
opposite. The idea with "predicting the future revocation
hashes/pubkeys" is you only need to send revocations. Instead, it's
possible to only send revocation hashes/pubkeys and not send
revocations. In other words, instead of predicting each others' future
revocation hashes/pubkeys, it's possible to revoke as *part of* giving
the next revocation hash/pubkey.
You can arrange something similar to a hashchain (shachain/elkrem is an
optimization of this, ignore optimizations for a second). We treat
privkey->pubkey as an elaborate hash function. I think if you
pre-compute it so that privkey -> pubkey, and then take the pubkey
output to create a privkey, you have a reversed list of items (let's say
you do this 100,000 times). The final privkey -> pubkey computation is
the first "revocation keypair" used. The pubkey->privkey step can do
anything you want, including hash functions if it makes you feel better
(this is the point where one can optimize).
(Note: I really mean EC point here, but it's simpler to understand it as
a pubkey)
If you want multiple in-flight, just have multiple parallel chains
(minor increase in permanent storage of counterparty's revocations). I
don't see any need for more than a handful in-flight. Note that this
explicitly breaks doing multiple in-flight on a single chain, since
disclosure of a pubkey is disclosure of all prior revocation states.
Essentially, what happens is when you disclose a pubkey, you are
providing the next pubkey AND revoking the prior one at the same time.
This construction is also possible using hashtree like structures if
you're using revocation hashes instead of revocation pubkeys.
For the pubkey revocation, a nested chain of privkey->pubkeys are needed
instead of hashes since you can't have a usable pubkey point without
also getting the corresponding private key.
Not sure how useful this is, though. Seems a lot of complexity for some
small bandwidth savings, not really that interested in doing all that,
but it's the closest I can get to what you want. This is off the top of
my head/memory, I didn't write any notes on this, so parts of this (or
entirety) might be wrong...
--
Joseph Poon

2023-06-09 12:46:34

- reply

📅 Original date posted:2016-08-09
📝 Original message:
On Wed, Aug 10, 2016 at 06:36:11AM +0930, Rusty Russell wrote:
> Yes, I think we agree some "filter hint" is needed to avoid a crazy
> amount of outsourcing work (eg. first 8/16 bytes of txid). I don't
> think an HMAC check per registered commitment is quite fast enough.
For #1, the HMAC would be pre-computed by the outsourcer. So the flow
looks like:
1. The outsourcer takes the txid, HMAC(txid+salt1) and encrypts the blob
2. The outsourcer gives the 32-byte hmac and blob to the watcher
3. The watcher adds the 32-byte hmac and the blob to a key-value store
(the watcher can optionally truncate or whatever)
4. When the watcher receives a new block, they HMAC(txid+salt1) all
transactions and compare against the key-value store
This method does not require significant computation upon receiving a
new block and checking against the datastore. I forgot to note, that the
salt2 is sort of unnecessary, it can just be the pure txid as the key
but was there for superstition and aid in understanding what's going on.
I was just making a point that there needs to be some kind of "hint"/key
to look for.
> > 2. HMAC the transaction itself (not txid) as the secret key (or anything
> > part of the transaction, as long as it isn't SHA256(tx) for obvious
> > reasons). I like something along these lines better than option #1.
> > Whatever computational cost there is will be extremely low, as the
> > operations are constrained by block size.
>
> If we include the witness in that HMAC we risk reintroducing
> malleability. If we don't, we risk txs being predictable.
I was referring to the non-witness txid when making that comment, but
there should be sufficient entropy from the revocation hash (whose P2WSH
is part of the Commitment outputs).
> I can think of a few fixes: insert some randomness in the tx (OP_RETURN?
> Different addresses each time?), or try to extract the input signature
> from the witness, which is unguessable, as our filter?
Yeah! I like this idea to use one's own input sig as the key for the
encrypted blob too. If Alice is the one outsourcing the Commitment which
Bob can broadcast, Bob can only broadcast it using the sig Alice gave
Bob as it's spending from a 2-of-2. If Alice is outsourcing Bob's
Commitment broadcasts, a hash of her input signature is a solid way to
derive a key as well without malleability concerns.
I also like that it "encourages" more nodes to download witness data;
ignoring witnesses is a concern of mine which this helps with :^)
--
Joseph Poon

2023-06-09 12:46:34

- reply

📅 Original date posted:2016-08-09
📝 Original message:
Hi Rusty,
On Tue, Aug 09, 2016 at 03:13:57PM +0930, Rusty Russell wrote:
> We send the observer the "steal" tx every update (not really: we only
> need to send the to-us/to-them amounts, pubkeys, HTLCs info and sig).
> This gets encrypted+HMAC with the txid of the commit tx (or, if that's
> too guessable, the SHA256() of our signature on the commit tx).
>
> [snip]
>
> If we want to obscure our funding tx, we can simply use a txid qualifier
> the same way you did (and maybe use the sha256(txid) as the encryption
> key to avoid weakening that).
I think it may be necessary to identify when the transaction occurs as
an index for outsourcing services, so the key can't be dervied directly
from the txid with a single HMAC/sha256. It's possible there are
millions of transactions to compare, and an index based on txid is
necessary. The two options I can see are:
1. Take the txid and use two salts (globally for all users).
HMAC(txid+salt1) and HMAC(txid+salt2). Give the result of
HMAC(txid+salt1) and the encrypted blob to the outsourcer. The first is
used for identifying the txid, the second salt is for the secret key and
can only be derived when the actual txid is seen. When a transaction is
received, do HMAC(txid+salt1) and see if there's any matches to decrypt
& broadcast.
2. HMAC the transaction itself (not txid) as the secret key (or anything
part of the transaction, as long as it isn't SHA256(tx) for obvious
reasons). I like something along these lines better than option #1.
Whatever computational cost there is will be extremely low, as the
operations are constrained by block size.
I do like encrypting the outsourcing blobs best as an approach so far,
as it gives maximum flexibility in terms of implementation (individual
client behavior can be upgraded in the future without modifying the
outsourcing code/nodes in most instances).
--
Joseph Poon

2023-06-09 12:46:27

- reply

📅 Original date posted:2016-08-19
📝 Original message:
On Fri, Aug 19, 2016 at 10:26:31AM +0930, Rusty Russell wrote:
> >> > While not dangerous it is rather unfortunate as it results in
> >> > guesswork. It is not dangerous because if A transferred litecoin to B
> >> > then B will (hopefully) never forward a higher value to C using
> >> > bitcoin, and if it were bitcoin then the final recipient would not
> >> > sign off an inferior amount than what he expected.
> >>
> >> Worse case: C is a charity, accepting donations. A's software screwed
> >> up and didn't realize C was litecoin, not bitcoin. B collects a huge
> >> fee, C gets tiny donation.
Yeah, for sure, I agree with y'all. By default, there should be a
requirement that the amount is pre-negotiated by the sender and the
recipient (pay-to-contract, etc.)
Sufficient percentages of senders to a charity should be interested in
getting a receipt to prove funds were sent to a charity that I don't
think pre-sending it without generating a proof shouldn't be a normal
case. By default, I don't think clients should even send funds until
they have a signed receipt before cross-chain is supported for safety.
However, I'm not too concerned with cross-chain. As long as there's some
identifier between each hop, I suspect that should be sufficient. Is the
intent of the realm byte to indicate protocols? I think it's reasonable
to have some kind of byte for identifying the message (e.g. using this
as a transport layer for other things), but I think there should already
be sufficient information for cross-chain, presuming pay-to-contract.
> > True, that's a dangerous scenario. If the recipient does not know the
> > intended amount and accepts anything then fee-shaving is very
> > profitable.
>
> Which creates a subtle requirement: even the terminal onion should
> include an amount.
This may not fully solve the problem, since if one presumes that the
second-to-last hop is malicious, they can re-create a new onion blob
(presuming consistent hashes for each hop, of course).
There may be a requirement from deriving the fee amount for the last
hop, though.
> > In general I'm a bit concerned about rhash re-use, after
> > all today it's not uncommon to just publish a bitcoin address, people
> > might be tempted to do the same in Lightning.
>
> Hmm, maybe we should implement the code to steal such re-sends? Or more
> generously, fail it. That would prevent this from becoming a habit, at
> least.
Either way seems practical for some nodes -- I presume if a small
percentage of nodes redeem without forwarding, then basically nobody
would re-use. Not sure if "steal" is the right word, though.
--
Joseph Poon

2023-06-09 12:46:05

- reply

📅 Original date posted:2016-04-01
📝 Original message:
On Fri, Apr 01, 2016 at 03:32:15PM +0200, Pierre wrote:
> Also @lnd guys: what's the thing with odd/even htlc ids? Is it just so
> that we can use the same keyspace for incoming/outgoing htlcs and
> quickly tell the direction of a given htlc, or is there something
> else?
Hi Pierre,
I've actually been going back and forth on HTLC IDs lately, and am
actually currently working on a cleaner solution -- I think you might
like it (provided it works out). The thinking was so that one is able to
uniquely identify HTLCs at a later time by having unique ID upon
creation (direction should be contextually understood by the
positive/negative amount). The ID doesn't really need to be in the final
wire protocol, it's more helpful for debugging than anything.
--
Joseph Poon

2023-06-09 12:46:02

- reply

📅 Original date posted:2016-03-18
📝 Original message:
Hi Anthony,
On Wed, Mar 16, 2016 at 07:27:44PM +1000, Anthony Towns wrote:
> What do you guys think?
Looks interesting, thanks for writing this and documenting -- I think it
will be very helpful going forward. I think there's some differences
with how our code works right now, it'll be good aligning designs going
forward. We will be putting up our specs in a couple weeks.
--
Joseph Poon

2023-06-09 12:45:52

- reply

📅 Original date posted:2016-03-10
📝 Original message:
Hi Nicolas,
On Tue, Mar 08, 2016 at 01:44:05PM +0900, Nicolas Dorier wrote:
> I am catching up with the latest dev of lightning. I thought you
> wanted SIGHASH_NOPINPUT in order to fix the problem of storage
> requirement.
> [...]
> I re-read slowly your post on bitcoin-dev about SIGHASH_NOINPUT, and
> noticed the problem it was to fix was for third party monitoring.
Yes, SIGHASH_NOINPUT is for the storage requirement. I was talking about
an implementation detail for using OP_CODESEPARATOR to ensure that the
signature is valid for multiple types of script outputs.
As a side point, I think to clarify to the rest of the list what Nicolas
has discovered for those who are skimming since I find novel/unusual use
of OP_CODESEPARATOR interesting, I believe Nicolas was talking about
noticing that an aspect of OP_CODESEPARATOR is you can use it to enforce
branch execution. For LN, however, the script can be made compact
without OP_CODESEPARATOR.
E.g. if part of the script looked like (ignore optimizations for a sec!)
<alicePubkey> #used for OP_CHECKSIG
OP_IF
[some kind of conditions, e.g. OP_CLTV, OP_HASH160, etc.]
OP_CODESEPARATOR
OP_CHECKSIG
OP_ELSE
[OTHER conditions, e.g. OP_CLTV, OP_HASH160, etc.]
OP_CODESEPARATOR
OP_CHECKSIG
OP_END
In this situation, a single pubkey can enforce execution of a particular
codepath. The codeseparator can enforce whether the first IF path is
executed or the ELSE statement, since a signature can only be valid for
one of the two paths. This is achieved since codeseperator selects which
part of the script to sign, which is a very interesting result.
While this doesn't allow you do things you weren't able to before, this
does offer potential space savings. It's possible to enforce code
execution with slightly larger scripts without using OP_CODESEPARATOR by
using two different pubkeys or by moving the conditions to be a nested
OP_IF statement.
This type of construction is interesting because there can be
multi-party multi-signature situations where a party only wants to sign
off on particular conditions are guaranteed to be executed, especially
if there is some interactive communication and out-of-band conditions
for signing.
--
Joseph Poon

2023-06-09 12:45:51

- reply

📅 Original date posted:2016-03-08
📝 Original message:
Hi Nicolas,
Yes, I do think exploring using signatures as a method of revocation is
interesting! For revoking Commitments, I believe if you did disclosure
of the private-key as a method of revocation, then it's possible to
achieve this compactness without using OP_CODESEPARATOR.
Side note: It's necessary to disclose temporary private keys (instead of
signatures) under this mechanism, since it's possible to compactly store
the keys by making it derived from a tree or chain of hash functions.
A compact revocable example for Bob to broadcast could be:
<PubkeyAlice> OP_CHECKSIG
OP_NOTIF
<CSVDelay> OP_DROP OP_CSV
OP_ENDIF
<PubkeyBob>
OP_CHECKSIG
On the other hand, if Alice broadcasted it, her script could be:
<PubkeyBob> OP_CHECKSIG
OP_NOTIF
<CSVDelay> OP_DROP OP_CSV
OP_ENDIF
<PubkeyAlice>
OP_CHECKSIG
Alice successful redemption of her broadcast would be:
(after one week)
<AliceSig> <0>
Bob's penalty transaction on Alice's broadcast would be:
<AliceSig> <BobSig>
If Alice did not broadcast the correct Commitment, Bob can take the
money immediately because she disclosed her private key when creating
the new Commitment transaction, so Bob has both PrivkeyBob and
PrivkeyAlice. If Alice correctly broadcast the most recent Commitment,
Bob does not have PrivkeyAlice so he cannot take the funds, but Alice
does not have PrivkeyBob so she has to wait for the CSV delay.
If the goal is to save space, it saves a little in the
timeout/non-penalty case, but the transactions are larger for penalty
cases (although they may be less frequent).
It's also possible to make it just a multisig output with the child
transaction spending from it pre-signed as well using nSequence, but
that requires more storage and more on-chain transactions (while saving
in the script output size), this design is not necessary for this
particular instance if there's OP_CSV.
As a side note, OP_CODESEPARATOR may become useful if there is
SIGHASH_NOINPUT inside segregated witness in the future, by being able
to have one signature be able to apply towards multiple types of
transactions (e.g. different redeemScript/scriptPubKey r-values or
pubkeys).
--
Joseph Poon

2023-06-09 12:45:45

- reply

📅 Original date posted:2016-02-26
📝 Original message:
Hi Bryan,
On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:
> Well if you are bothering to draft up a BIP about that SIGHASH flag,
> then perhaps also consider some other SIGHASH flag types as well while
> you are at it?
I'll take a look at those proposals when drafting the BIP. I think for
LN, there is a single clean way to achieve outsourcability, but may be
compatible with other arrangements. I'm somewhat averse to proposing too
much flexibility before there's clear use-cases, though. However, if
others do have uses/examples for other sighash flags, I'd be very
interested while drafting this BIP!
> FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
> http://gnusha.org/bitcoin-wizards/2015-04-07.log
Yeah, I think the nice thing about SegWit is that you resolve
malleability without worrying about replay attacks in the event of key
reuse. That's why I think it's only safe to do this new sighash type
inside segwit itself -- if you only wanted protection against
malleability you'd use segwit, and not touch this new sighash type
(you'd only use the new sighash flag if you actually need its features).
--
Joseph Poon

2023-06-09 12:45:42

- reply

📅 Original date posted:2016-02-08
📝 Original message:
On Tue, Feb 09, 2016 at 06:47:07AM +1030, Rusty Russell wrote:
> Eliminating all acknowledgements makes for a much simpler
> protocol.
For adding HTLCs, this may be an option, but there are some tradeoffs.
The downside of doing this is that it's uncertain whether the other
party has received the message. Essentially, the moment the packets are
sent over the wire, it should be assumed the other party can broadcast
(TCP SACKs cannot be relied upon, of course). To remove the HTLC
securely, it requires removing the HTLC, committing, and then the other
party revokes the prior commitment. If the ratio of success/failure is
high enough it can be worth it. This may have some disadvantages with
intermittently connected nodes, as requiring confirmation has a
significantly smaller time window for non-responsive payments. I'm
optimizing against payment failure on the ADD side, as failure may
require a re-route in the opposite direction to do a full cancel with a
non-responsive node in multi-hop payments (as an add request/accept
structure has lower time windows for going offline). However, I agree if
both nodes are well connected, then this is more optimal if latency is
the primary concern.
--
Joseph Poon

2023-06-09 12:45:41

- reply

📅 Original date posted:2016-02-03
📝 Original message:
On Wed, Feb 03, 2016 at 03:05:33PM +1030, Rusty Russell wrote:
> Right, so "this signature covers you up to X me up to Y". That resolves
> the in-flight issue.
>
> But isn't that more a request ID rather than an HTLC ID? Since requests
> can include removing HTLCs as well? And doesn't that simply degrade to
> a counter?
Yeah, it's more like a request "staging" ID. The "counter" aspect
requires two counters (one for each originator of the request). Two IDs
sent in the commitment message allow for simultaneous action on
accept/reject/etc, whereas only one would require a lock on
accepting/rejecting modifications.
Minor note which has the potential to be overlooked: It's a hard
requirement that all messages sent are in order, and if the replyer
skips the requester's Add Requests when replying, the skipped are
assumed to be request rejections (or an outright channel closeout) since
it should never happen -- this is to enforce accept/reject order, as we
need to know which modifications are included in the
signature/transaction and not have that change after-the-fact.
--
Joseph Poon

2023-06-09 12:45:40

- reply

📅 Original date posted:2016-02-02
📝 Original message:
Hi Rusty,
For synchronous across-the-wire commit steps, 3 steps is a good idea and
more secure than 2 steps for the commit transaction.
However, the nice thing about keeping everything asynchronous is it
simplifies orchestration and no locking across-the-wire. We have a
preliminary explanation on the git repo in the README.md file.
--
Joseph Poon

2023-06-09 12:45:40

- reply

📅 Original date posted:2016-02-02
📝 Original message:
On Wed, Feb 03, 2016 at 11:02:50AM +1030, Rusty Russell wrote:
> I guess it depends how we count steps. Each party needs to receive the
> signature for the N+1 commit tx before handing over the Nth revocation
> preimage, but that's the only irreducible constraint isn't it?
Correct, that is a necessity for a secure implementation.
> It's probably simpler to do a three way handshake on every stage, but I
> didn't see that in your protocol?
Unlike a 3-step synchronous commitment, it doesn't wait for the other
party to send their sigantures/revocations and can happen
simultaneously.
Bob's broadcastable Commitment: Alice sends a Signature to Bob. Bob
sends the Revocation of the previous Commitment to Alice.
Alice's broadcastable Commitment: Bob sends a Signature to Alice. Alice
sends to Revocation of the previous Commitment to Bob.
It's that simple. If the HTLC is reflected in both and the previous
commitment(s) is/are revoked, then it's complete.
> If I receive "add request" "add request" "signed commit", how do I know
> what that signatures covers?
The protocol is still being optimized (deprecating the even/odd
structure, etc.), but the structure is both parties have a list of HTLC
modifications which they want to update. When the modification is
acknowledged by the other party, the HTLC modifcation request is staged
into the next Commitment signature. The inclusion of modifications are
enumerated by including both parties' higest HTLC ID (two of them) in
each Commitment signature message.
> Are you required to wait for my accept/reject message replies before
> commiting? Or does the commit message include a counter?
Any which is accepted by the other party is included. Two IDs, one for
each party, is included. Two are necessary to allow for timing issues
with HTLC Add responses in-flight not being fully synced up.
> I guess "asynchronous" is a bit nebulous: out-of-order or in-order? I
> couldn't see a good reason for out-of-order. Whereas letting both
> sides offer updates in parallel makes good sense for throughput...
In-order. I should have an update in the coming days for lnstate if that
helps (various protocol updates, e.g. fixing exchanging of revocation
hashes, etc.)
--
Joseph Poon

2023-06-09 12:45:31

- reply

📅 Original date posted:2016-01-16
📝 Original message:
TL;DR: It's possible to do 2-of-3 party escrow in Lightning,
functionally the same as the use case for on-chain "2-of-3 multisig"
escrow systems (without the 3rd party escrow being a custodian for any
funds! Or anyone else holding custodial ownership of coins for the
matter). As Lightning uses Bitcoin transactions and scripts (using
Bitcoins, not 3rdPartyCoins), it'll be possible to do nearly *instant*
*offchain* multisig "escrow" on decentralized Lightning! This is useful
for payments for goods and services which needs a 3rd party mediator.
By making multiple R-value hashes supported in HTLCs, you can do
something equivalent to "multisig" where payments are conditional upon
2-of-3 parties agreeing. This is to support conditional multiparty
payments, e.g. 2-of-3 "escrow", which is one of the biggest use cases of
bitcoin scripting today. An example use case is a 3rd party escrow
verifies whether a seller should be paid. This design is such that the
escrow is not a traditional custodial escrow, but instead determines who
should get the money in the event of non-cooperation. See the Bitcoin
Script below for details.
There isn't message integration for 2-of-3 yet, but can work with *very*
minimal changes. Arbitrary N-of-M can be supported with M values higher
than 3 and lower than max script size, but let's keep this simple for
now!
How it works: Require 2-of-3 R-value preimages (from 3 hashes) in order
for the HTLC to be fulfilled. For each hop in the payment, it requires
this 2-of-3 condition. The timeout minimum for each hop in the path is
at least the minimum agreed contractual escrow timeout. The timeouts
should be fairly long compared to straight payments for security and
giving enough time for the escrow service. This means each hop consumes
a higher amount of time-value (due to much longer timeouts along all
channels in the path, and possibly higher fees to pay for larger scripts
and greater time-sensitivity for transaction inclusion), which does have
greater pressure towards lower hop-distances, compared to straight
payments where it matters a whole lot less.
This is a slightly different way of thinking about things. It's not
signatures that the escrow produces (or for that matters any of the
3-parties in the 2-of-3 after the actual Commitment is signed). It's
some secret which is revealed to authorize payment. So if the escrow
wants the payment to go through without cooperation of the sender, they
disclose the secret (R-value) to the recipient. If the recipient is
unable to produce 2-of-3, after the agreed timeout, the sender will be
refunded. Sender and receiver can agree to authorize payment in most
cases where there is cooperation, escrow is only contacted if there is
non-cooperation.
Assume the order in the stack is Sender, Escrow, Recipient.
For PAID 2-of-3 Escrow+Recipient, the HTLC stack is:
<BobSig> <0> <EscrowPreimageR> <RecipientPreimageR> <0>
If it's REFUND because 2-of-3 has not been redeemed in time:
<AliceSig> <0> <1>
Bitcoin Script (Alice's, we use OP_1/OP_0 to distinctly show computed
true/false. 0/1 is for supplied data as part of the
sigScript/redeemScript stack):
------------------------------------------------------------------------
//Paid
OP_IF
<CSVDelay> OP_DROP OP_CSV //under rusty's CSV style
//Stack: <BobSig> <0> <EscrowPreimageR> <RecipientPreimageR>
//Recipient must agree to receive funds.
OP_HASH160 <RecipientHash> OP_EQUALVERIFY
//Stack: <BobSig> <0> <EscrowPreimageR>
//Either the Sender or Escrow must consent for payment
OP_HASH160 <EscrowHash> OP_EQUAL
//Stack: <BobSig> <0> <OP_1>
OP_SWAP
//Stack: <BobSig> <OP_1> <0>
OP_HASH160 <SenderHash> OP_EQUAL
//Stack: <BobSig> <OP_1> <OP_0>
OP_BOOLOR
//Stack: <BobSig> <OP_1>
OP_VERIFY
<BobPubKey>
//Stack: <BobSig> <BobPubKey>
//Refund
OP_ELSE
//Stack: <AliceSig> <0>
OP_HASH160 OP_DUP
<R-HASH> OP_EQUAL
OP_NOTIF
<CSVDelay> OP_DROP OP_CSV
OP_ENDIF
<HTLCTimeout> OP_DROP OP_CLTV
//Stack: <AliceSig>
<AlicePubKey>
//Stack: <AliceSig> <AlicePubKey>
OP_ENDIF
OP_CHECKSIG
------------------------------------------------------------------------
Note: It is possible that Alice and Bob may not be Sender, Recipient,
nor Escrow! They could be nodes along the routing path. Script might
have a typo or two or might be able to be optimized a couple bytes
smaller maybe? Also, the script would be a bit different depending upon
is broadcasting due to the revocations/R-HASH.
The result? We can do 2-of-3 escrow payments which refund to the sender
after a timeout! The Sender and Recipient can agree to redeem and they
only need to go to the Escrow if there's a dispute. All nodes along the
path gets paid or refunded atomically, the same as a single-HTLC payment
on Lightning. Escrowed payments can be nearly instant and off-chain (but
enforced/net-settled ultimately using the blockchain).
Proposed HTLC wire message for the uint8 (two 4-bit N-of-M) determining
type:
0x11 (00010001): 1-of-1
0x22 (00100010): 2-of-2
0x23 (00100011): 2-of-3 [with Recipient being 1 of the two N parties]
0x33 (00110011): 3-of-3
I think the only ones that really matter are 1-of-1, 2-of-3, and 2-of-2.
1-of-2 and 1-of-3 doesn't make sense if the recipient must consent to
receiving funds anyway (pushing funds w/o consent is tricky due to
pay-to-contract-hash) so that's basically a 1-of-1.
Possible Resolution States:
* Recipient paid: Recipient and Sender provide R-values
* Recipient paid: Recipient and Escrow provide R-values
* Sender refunded via timeout: Sender is refunded if Recipient cannot
convince Escrow or Sender to disclose their R-value before HTLC
timeout
* Payment immediately cancelled and Sender gets refunded: Payment sent
in the opposite direction enforced by same R-values (if there is
sender & receiver consent/cooperation to cancel payment)
Sender+Escrow isn't going to want to push funds w/o cooperation of
Recipient. However, it's possible to construct a script that way.
Escrow is only contacted if the recipient needs to redeem and the sender
is uncooperative so this is still true to the "lazy escrow service" in
Bitcoin multisig.
Ta-da! "Smart Contract(TM)" meme on Lightning.
P.S. Tadge, Laolu, and I have also put up a repo of our in-progress
design/code for Lightning here: https://github.com/LightningNetwork/lnd
--
Joseph Poon

2023-06-09 12:44:38

- reply

📅 Original date posted:2015-09-24
📝 Original message:
Hi Mats,
Yes, I agree whole heartedly! See my related comment here:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000018.html
Two hashes are necessary for this type of invalidation.
On Thu, Sep 24, 2015 at 03:26:30PM +0930, Rusty Russell wrote:
> Mats Jerratsch <matsjj at gmail.com> writes:
> > So far my impression was that an attacker that only stops one payment
> > is just a nuisance, as the system can self-correct. The payer and
> > payee can set a timeout. If the payment has not arrived after the
> > timeout the payee can issue a refund back to the payer. The refund
> > will pay to the same secret hash as the initial payment, and it will
> > pay an amount that is sufficient such that the payer will receive his
> > initial payment completely back. (That is, he might end up paying more
> > refund than actual payment)
> >
> > When the payer does receive the refund in his channel, he can be sure
> > that the payment got invalidated. The payee must not reveal the
> > secret, and even if he does, the funds will just circle back again.
> > (plus the payee will pay fees for both transactions as a disincentive)
> > This concept has been around already, at least I read it somewhere.
>
> Yes, I think it was Joseph Poon who suggested it. I'm keeping it in
> reserve for the moment, in case this becomes common enough that we need
> to code up a solution.
Yes, seems like something to tack on later.
--
Joseph Poon

2023-06-09 12:44:04

- reply

📅 Original date posted:2015-08-20
📝 Original message:
On Fri, Aug 21, 2015 at 12:12:15AM +0200, Anthony Towns wrote:
> But C could achieve that outcome on its own, just by delaying
> notifying B until near the timeout; no collusion necessary. In any
> event, if the transaction's going to succeed, the money on the B-C
> channel's HTLC is going to be C's, so C is mainly depriving itself by
> filing to communicate.
Yes, the point is that pending sends between participants in this cartel
have a shorter time than outside this cartel. So the point is that
C<->D<->E links will always have shorter HTLCs in transit than B's. It's
only C holding it up, but before that D and E decided not to hold it up.
> If you have B and D collude instead, so that E reveals R to D, and D
> reveals R to B instead of C, then the payments could go:
>
> D pays E
> D reveals R to B
> A pays B
> B pays D
>
> with the transaction from B->C and C->D remaining open until the
> timeout, but everyone else is square.??? That would inconvenience C,
> possibly cheaply for B and D. If there's already a channel between B
> and D (for the "B pays D" step), I'm not sure why B and D wouldn't
> just announce that, and once it was announced, I don't see why A would
> route via C anyway...
Perhaps I may be misunderstanding things, but the purpose of not
announcing is to collectively make any paths to C delay closing out the
HTLC as long as possible, so that anyone that transacts with C has to
wait a long time, which will decrease the incentive to transact with C.
So the threat is that if C is being attacked, and B is not colluding,
then A and B will dislike transacting with C, even though it's not C's
fault. There's insufficient incentive to push funds when closing out the
HTLC (as opposed to pulling), e.g. A->B, due to the off-chance they
forget, but I may be wrong here, this is a bit speculative.
--
Joseph Poon

2023-06-09 12:44:03

- reply

📅 Original date posted:2015-08-20
📝 Original message:
On Thu, Aug 20, 2015 at 03:19:29PM +0930, Rusty Russell wrote:
> So, with some prompting from AJ who has been working on node
> incentives, I realized there's a nasty attack available to the
> network. You simply route a payment back to another channel you own,
> then refuse to dislose R.
>
> You have to lock up N bitcoins, but so does every node in the path
> (and nobody gets paid!). Onion routing means nobody knows who to
> blame (you can simply claim there's another hop after you).
This can be defined as a feature, though. If one expects the coins to be
locked up for the duration from the outset, the risk models are a lot
more clear.
It forces the graph to be more diffuse. It also forces intermediate
nodes who are well-connected (who therefore also are the most likely
subject of attacks) to offload their HTLCs to 3rd party channel
liquidity providers.
E.g. If Mallory tries to tie up the Alice<->Bob link, then if Carol is
connected to both Alice and Bob, she can take the HTLC to be
Alice->Carol->Bob, so that the Alice<->Bob link is clear.
> I think in this case we need to peel the onion[1]: if a payment takes
> too long you tell the previous node where you sent it (and relay where
> it sent it, etc.) If you're the last in the queue, you also need to
> prove that you closed the channel to the offender[2] (which costs you
> a txfee, providing disincentive).
My concern with mitigating this by establishing blame via information
disclosure is that it will encourage graph centralization.
> Anyone see any other problems?
I see the primary problem with "onion" routing is that some parts of the
graph may be faster with disclosure of R. In effect, some people may
have higher costs in the "time" part of "time-value"
E.g. A->B->C->D->E. If C, D, and E are colluding participants to each
other, and their R gets disclosed immediately, their channel's value
permits much lower fees. They can collude to be dishonest with B, so
that B's channel is tied up for the maximum period of time. This
increases the costs for B and biases channels to use the C,D,E cartel
due to lower costs (since the channels aren't locked up as long).
However! The effect isn't necessarily that the cartel is successful,
there are always second order effects in preventing potential problems.
It's possible that B mitigates this by biasing the routing towards
certain participants that B "likes" (IOW, trusts to not withhold R to the
maximum time), which is where I think the real complexity with
incentives lie -- B will discourage using onion routing entirely.
I see the tradeoffs as having both as an option may make sense, the
second order effect gives you an option for either (with one possibly
being slightly more expensive due to the withholding risks), whereas
forcing onion *only* on everything may create emergent cartelization
incentives. I haven't fully thought out the implications, and not
particularly attached to this viewpoint, though.
Thaddeus mentioned a possible solution to all this being funds sent to
each participant with multiple signatures for different times of
disclosure of R (having the spending transaction be double-spent with
different locktimes, this is dependent upon a longer-term malleability
fix and may require a more elaborate tree structure for the HTLC
spends). E.g. release within 4 hours will have each hop make slightly
more money in fees. It doesn't guarantee against withholding, it just
creates a material cost to do so. I don't think we've really fleshed out
the idea, though AFAIK.
--
Joseph Poon

2023-06-09 12:44:02

- reply

📅 Original date posted:2015-08-13
📝 Original message:
Hi Mats,
Yes, I agree that this is a possibility.
I had discussed this model of OP_CLTV without OP_CSV using a balance
reserve on the mailing list, along with some caveats on the
risks/effects of doing so.
Message ID: 20150727193714.GA16768 at lightning.network
Link:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000070.html
On Thu, Aug 13, 2015 at 08:37:18PM +0200, Mats Jerratsch wrote:
> Joseph asked, what changes OP_CLTV would bring to my Thunder proposal,
> and I started working out, how much is actually possible with only
> CLTV implemented.
I think very minor changes to the code would result in full lightning
channels, as per Rusty's doc, yes. I think there will be huge benefits
to Bitcoin if bitcoinj has an implementation ready when OP_CLTV/OP_CSV
is implemented.
--
Joseph Poon

2023-06-09 12:44:01

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hi Anthony,
Yes, reorg attacks are definitely a known with Bitcoin. You can send
money to an exchange and then double-spend withdraw several
confirmations later if you have infinite hashrate.
With lightning, I think to fund the channel, the minimum confirmation
times should be fairly high (even above 6 confirms). If a 120-block
reorg occurs, bitcoin is pretty busted anyway, might be of out-of-scope
with Lightning. IMO, lightning reduces this attack.
The nice thing about payment channels is that after it's set up, you
don't worry about confirmation times if it's off-chain. For that reason,
confirmation times (and block mining rate, ~10 minutes) matters a lot
less.
On Wed, Aug 12, 2015 at 03:38:16AM +0800, Anthony Towns wrote:
> Hi,
>
> This is probably just stating the obvious. Sometimes that's useful though,
> and maybe this is one of those times!
>
> When setting up a new channel with an untrusted counterparty, you will wait
> for N confirmations of their anchor transactions. Further, N might be well
> known and common amongst a lot of lightning hubs (if it's not, then it will
> be hard to know how long setting up a channel will take). What if N is too
> small, and I can afford to do a double-spend despite M (M > N)
> confirmations as long as it gains me $X?
>
> Then I do the following:
>
> - I open one or more anonymous channels, capable of receiving at least $X
> - I start the doublespend fork
> - I then simultaneously construct multiple lightning channels, funding
> them at $d each.
> - I wait for N confirmations so my new channels are active.
> - I quickly route multiple payments from my new channels to my anonymous
> channels until I can't send anymore
> - I publish the doublespending fork, so that my $d*n never got spent
> - I close my original anonymous channels gaining $X <= $d*n
>
> The only people worse off are the ones who opened the $d channels after N
> confirmations -- any intermediary hubs are fine. Those hubs didn't have to
> commit any funds to the new channels for the attack to work; the money they
> lose was that in other channels they used to route my payments forwards.
>
> With onion routing, none of the ripped off hubs need know where the money
> ended up, so there's not a lot of potential to do iron pipe cryptography to
> get your money back.
>
> The only constraints here (I think) are:
>
> - how many channels you can open in M-N blocks
> - you have to have >$X funds available in the first place to commit to the
> double spend
> - how much capacity the lightning network actually has in routable bitcoin
>
> If it costs 1.4*25*M bitcoin to mount a doublespend attack over M blocks
> (ie bribing 67% of hashpower for the time it normally takes to do 2*M
> blocks), and you can open 2000 channels per block, then that gives
>
> X > 1.4*25*M
> n < 2000*(M-N)
>
> X < d*n = d*2000*(M-N)
>
> 1.4*25*M < X < d*2000*(M-N)
> 35/2000 * M < d * (M-N)
> 35/2000 * (1 + N/(M-N)) < d???
>
> Setting N = 12, M = 15 gives:
>
> d = 35/2000 * (1+4) = 7/80
> n = 6000
>
> so you're putting up 525 bitcoin by flooding the blockchain with anchor
> transactions, sending it to yourself over lightning, then doublespending
> the original 525 btc at a cost of spending ~505 btc on hashpower. Expensive
> ($157k capital to make $6k profit), but still worthwhile (3.8% ROI in ~6
> hours is 16% a day, or about 5e25 % annualised...)
>
> Maybe if you make N depend on d you could mitigate this though -- something
> like, if you to put "$d" on your side of the channel, you'll have to wait
> for 5+(d*2000/25)*2 confirmations. So a $50 channel is d=.2 BTC, which is
> ~37 confirmations, or about 6 hours. Increasing the blocksize (number of
> channels openable per block) or lowering the block reward (decreasing the
> cost of a doublespend fork) increases the confirmations required though...
>
> Cheers,
> aj
>
> --
> Anthony Towns <aj at erisian.com.au>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
--
Joseph Poon

2023-06-09 12:43:59

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hi Mats,
On Tue, Aug 11, 2015 at 10:44:27PM +0200, Mats Jerratsch wrote:
> Do you mind if I start calling it a Lightning Network Implementation
> then? ;)
I can't stop you from calling it whatever you want, however, I'm just
concerned with any system which has some implicit level of trust,
especially with long-term systemic risks (e.g. implications for
fungibility, and other social accessibility costs). The goal of LN is to
allow you to connect to anyone without the risk of the counterparty
outright stealing or encumbering funds.
So if the purpose is to get it working today with some trust
compromises, then any potential design trust issues may be associated
with LN. I don't want to encourage the use of systems which lets you
maliciously encumber HTLC funds in transit and funding on main-net. As
much as I would absolutely appreciate how a semi-trusted implementation
would help counter the "Lightning doesn't exist" meme, it seems simpler
to test with the new opcodes using dummy opcodes on testnet. I think we
need not only the opcodes, but also long-term I see some kind of
malleability fix and timestop as ideal if not necessary.
> Also note that both these problems can be eliminated with OP_CLTV,
> which will be implemented at least somewhat soon.
Yes, if it uses the new opcodes similar to Rusty's construction, then
it's a LN implementation for sure (it will especially help with HTLCs in
transit). Do you expect any significant differences (beyond a balance
reserve for just OP_CLTV)? I think a bitcoinj implementation of
Lightning is sorely needed, for sure, and greatly appreciate any
implementation, as it's a huge positive step for the bitcoin ecosystem!
I feel like we might have gotten off on the wrong foot here (partially
due to me misunderstanding the design), I think we both agree that
scalability of bitcoin micropayments is something that is very important
to the wider ecosystem and I'm looking forward to continuing developing
these techonlogies with you!
--
Joseph Poon

2023-06-09 12:43:59

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hi Jasper,
On Tue, Aug 11, 2015 at 10:48:57AM -0700, Jasper Hugunin wrote:
> I'm Jasper Hugunin, a developer at HashPlex. I have implemented a full
> prototype Lightning node in Python and will be releasing tomorrow.
>
> Features include:
> Micropayment channels supporting unilateral close.
> Basic routing support which allows payment to be routed multiple hops.
> Integration tests.
> MIT License.
Very cool, I'm looking forward to it!!
--
Joseph Poon

2023-06-09 12:43:58

- reply

📅 Original date posted:2015-08-11
📝 Original message:
On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:
> > At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
> > At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
> >
> > Alice is the client and Bob is the server.
> >
> > Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> > version of Commitment 20. The server is out 1 BTC! This is now a hostage
> > negotiation.
>
> But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
> multi-sig address). Mutating a channel transaction only hurts the
> party that is doing the mutation. This is why RBF is a major problem,
> if it ever gets deployed.
Sorry, I usually use Bob as the attacker in my examples and Alice as the
client, so I got mixed up there. I meant:
At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.
At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.
In this case, if Alice attacks Bob she's not out any money, but Bob has
funds locked up in a 2-of-2. Bob must now negotiate with Alice to get
his money back. Alice will probably want some 'convenience fee'.
>
> > Let's presume that you set up some kind of reserve requirement instead:
> > At Commitment 20, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> > At commitment 31, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
> >
> > Again, Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
> > version of Commitment 20. The server is out 0.95 BTC! But wait, you say,
> > Alice might be out 0.05 of her own BTC. This model breaks down because
> > it's still a hostage scenario! Alice tells Bob, "hey, I know I have 0.05
> > BTC stuck here (and you have 0.9 stuck), but I'm rich. I don't care how
> > long it takes, how about you give me a 'tax' of 0.1 BTC. You'll get your
> > money back... well most of it, just sign this transaction where I get
> > 0.15".
>
> The same as above, if she resignes commitment 20, she is losing 0.05
> BTC, while Bob does still get the 0.95 BTC.
At Commitment 20, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
At commitment 31, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
> There is a problem with channel histories, where Alice holds all the
> funds at one point, and Bob holds all the funds at some later point,
> as open payments are not as secure as those settled balances. I
> mitigate this by setting a hard requirement on the spendable amount. I
> will describe this in more detail soon.
You can't mitigate this by setting some reserve requirement, though. So
long as Alice has more money than Bob, she can do it. If Alice is 10x
richer than Bob, she doesn't *care* and she knows Bob will eventually
give up. "Two-party escrow" doesn't work because one party can have more
money and less time-value than another. Time-value is not a universal
value.
--
Joseph Poon

2023-06-09 12:43:58

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Ah I see, if you use a hash-based revocation, then the only primary
attack vector left is with the Funding and HTLCs (which can be
partially mitigated with a reserve)
On 8/11/15, Mats Jerratsch <matsjj at gmail.com> wrote:
> 2015-08-11 22:06 GMT+02:00 Joseph Poon <joseph at lightning.network>:
>> On Tue, Aug 11, 2015 at 09:26:43PM +0200, Mats Jerratsch wrote:
>>> > At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
>>> > At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
>>> >
>>> > Alice is the client and Bob is the server.
>>> >
>>> > Presume Alice deicdes to be a jerk! She broadcasts a mutated
>>> > (re-signed)
>>> > version of Commitment 20. The server is out 1 BTC! This is now a
>>> > hostage
>>> > negotiation.
>>>
>>> But the 1 BTC of Commitment 20 goes straight to Bob (and not to a
>>> multi-sig address). Mutating a channel transaction only hurts the
>>> party that is doing the mutation. This is why RBF is a major problem,
>>> if it ever gets deployed.
>>
>> Sorry, I usually use Bob as the attacker in my examples and Alice as the
>> client, so I got mixed up there. I meant:
>> At Commitment 20, the channel state is 1 BTC to Alice and 0 to Bob.
>> At commitment 31, the channel state is 0 BTC to Alice and 1 to Bob.
>>
>> In this case, if Alice attacks Bob she's not out any money, but Bob has
>> funds locked up in a 2-of-2. Bob must now negotiate with Alice to get
>> his money back. Alice will probably want some 'convenience fee'.
>>
>
> But Bob has both keys of the 2-of-2 multisig. One is his (main) key,
> and the other one was supplied by Alice as a requirement to update the
> channel and move funds.
> But that is what I meant with mitigate it. Even if Bob claims all
> payments, he will lose funds due to blockchain fees. (see below)
>
>> You can't mitigate this by setting some reserve requirement, though. So
>> long as Alice has more money than Bob, she can do it. If Alice is 10x
>> richer than Bob, she doesn't *care* and she knows Bob will eventually
>> give up. "Two-party escrow" doesn't work because one party can have more
>> money and less time-value than another. Time-value is not a universal
>> value.
>
> It is possible to say that the minimum (stealable) amount of Alice
> must be higher than any sum of concurrent payments minus the
> blockchain fees. This way Bob can always claim all the payments of all
> Commitments of the Channel and still stay in positive net balance. It
> really comes down to having an incentive to clear out payments of the
> channel. Only open payments are problematic, settled balance can
> always be stealed with just one transaction.
>
> Mats Jerratsch
>

2023-06-09 12:43:57

- reply

📅 Original date posted:2015-08-11
📝 Original message:
On Tue, Aug 11, 2015 at 08:42:50PM +0200, Mats Jerratsch wrote:
> Can you elaborate, why you think that the client is not able to close
> the channel? I think this is a misunderstanding on your side, which
> most of the rest of your post argues from. While there is a slight
> favor for the server in the channel design, there is nothing what
> prevents the client from broadcasting (and enforcing) the channel.
Ah, sorry, i'm reading it more closely now. I assumed only the server
had a copy since that what made the most sense to me under this kind of
asymmetric model, since it makes sense to not trust the client.
In this case, the client can hold up funds from the server completely
and attack the server by mutating their transaction.
Presume Alice and Bob have a channel open together. They both
contributed 0.5 bitcoin for a total balance of 1 BTC.
At Commitment 20, the channel state is 0 BTC to Alice and 1 to Bob.
At commitment 31, the channel state is 1 BTC to Alice and 0 to Bob.
Alice is the client and Bob is the server.
Presume Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
version of Commitment 20. The server is out 1 BTC! This is now a hostage
negotiation.
Let's presume that you set up some kind of reserve requirement instead:
At Commitment 20, the channel state is 0.05 BTC to Alice and 0.95 to Bob.
At commitment 31, the channel state is 0.95 BTC to Alice and 0.05 to Bob.
Again, Alice deicdes to be a jerk! She broadcasts a mutated (re-signed)
version of Commitment 20. The server is out 0.95 BTC! But wait, you say,
Alice might be out 0.05 of her own BTC. This model breaks down because
it's still a hostage scenario! Alice tells Bob, "hey, I know I have 0.05
BTC stuck here (and you have 0.9 stuck), but I'm rich. I don't care how
long it takes, how about you give me a 'tax' of 0.1 BTC. You'll get your
money back... well most of it, just sign this transaction where I get
0.15".
--
Joseph Poon

2023-06-09 12:43:56

- reply

📅 Original date posted:2015-08-11
📝 Original message:
Hi Mats,
Interesting work on payment channels, I think a lot of the bitcoinj code
can be used for further development as the necessary bitcoin softforks
for LN are incorporated. A bitcoinj implementation for lightning would
be great!
On Tue, Aug 11, 2015 at 06:12:04PM +0200, Mats Jerratsch wrote:
> I present you a implementation for a Lightning Network Payment-Hub +
> Client. Everything is written in Java and can be accessed on
Can you do me a big favor and not call this an implementation for
Lightning Network, though? I would prefer some name like "payment
channel networks" or something similar, as it's materially different in
design and trust models. In particular, if exit scams occur, I don't
want it to be associated with Lightning Network.
> I made some changes to the channel design to have everything working
> on the current Blockchain, without the need for softforks. Due to
> that, the network is no longer no-trust, but low-trust. This will
> change with the upcoming new OP_CODES.
Yeah, a lot of the code can definitely be used for a full LN
implementation when the opcodes come in for sure!
> The provided wallet is just a prototype, I will focus on building a
> potent backend in the future. There are many wallets out there
> already, it will be much more useful if those add these
> functionalities.
Some quick feedback (might have more later):
* I don't think a dual-Commitment structure is necessary if only one
party can close out the channel. The purpose of having two Commitments
is so that the payout structure is different. In this case, since only
the server can broadcast the final balance (and the client has no way
to close out the channel), only the B Commitment is necessary).
* HTLCs have significant malleability risks with malicious servers
(hostage scenarios).
* If you presume full-RBF (which I think is a game-theoretic
eventuality), clients can pay a higher fee to mutate the server's
broadcast of the Commitment, which will result in the server's funds
being held up permanently until the server is willing to negotiate
(malleability hostage scenario).
* Exit Scamming is a distinct and likely possibility. The server can
develop a good reputation for a while, then decide to screw over
everyone. The server refuses to do any further transactions in any
channel which has funds in the clients favor (current channel balance
for the client is above what was funded). With the timeout, the server
gets the original deposit back, which is above what they should get
back, in other words, the server steals your money.
* This creates an asymmetric playing field. If one cannot be confident
they will receive their funds back, this is similar to depositing your
money on a hosted wallet such as Coinbase or whatever. The primary
value of transacting on bitcoin is that the social costs of
counterparty risks are minimized -- and counterparty risk is one of
the primary inputs on interest rates (remove trust -> remove
counterparty risk -> remove fees/interest). This can only exist if
you're sufficiently willing to transact with nearly anyone (minimal
underwriting).
> Furthermore, as there are less everyday payments on the blockchain,
> there is more space for important transactions of higher value.
I agree that this is one of the primary values of payment channel based
systems. To extend and take your point in a different direction, there
is a risk if everyone uses blockchain transactions for every day
purchases, that high-value transactions will crowd out low-value
transactions. There is a tension that exists between the need for
sufficiently high fees to pay miners (when the block rewards decline)
and allowing low-fee transactions to be on-chain in a timely manner.
--
Joseph Poon

2023-06-09 12:43:49

- reply

📅 Original date posted:2015-07-29
📝 Original message:
Hi Eric,
On Wed, Jul 29, 2015 at 02:08:39AM -0700, Eric Lombrozo wrote:
> It occurs to me that with the LN, it might be practical to outsource
> SPV proofs from other nodes.
I couldn't find anything on an SPV proof opcode, what kind of opcode are
you thinking of or do you have any links? I tried looking it up but
couldn't find anything about it. I'm curious on whether/how it could it
offer significantly better security than current SPV proofs.
--
Joseph Poon

2023-06-09 12:43:48

- reply

📅 Original date posted:2015-07-27
📝 Original message:
On Mon, Jul 27, 2015 at 11:58:12AM +0930, Rusty Russell wrote:
> The asymmetric risk is as much a feature as a problem: with the
> dual-anchor proposal, either side could abort with no penalty and make
> the other side wait for the escape timeout anyway.
Cool, I think this works.
Yeah non-cooperation risks in this model aren't that big of a deal,
because the channel is going to be closed out anyway if they're not
cooperative -- they could always refuse to route payments, and then
everyone's going to get their money back.
> We've handwaved over the incentives for channel creation so far; they're
> tied with routing, and not immediately clear to me. But it doesn't seem
> unreasonable that if you connect to a hub, you front the funds.
Yeah, there's likely some weird asymmetric economic incentive things
going on. If both channels are established with the same person, it
should be fairly clean, though. I think there will probably be some
measure of trust/reputation involved with pre-payment of the time-value
for the channel (shorter with OP_CSV, but still non-zero).
OP_CSV still requires BIP 62, though. It's possible to construct a model
with OP_CLTV without BIP 62 (described in a post earlier today) using
single-funder with some OP_CLTV'd output which returns the full balance
to the original funder at a date very far in the future after the
expiration of all Commitments and its dependent outputs.
--
Joseph Poon

2023-06-09 12:43:47

- reply

📅 Original date posted:2015-07-29
📝 Original message:
On Tue, Jul 28, 2015 at 11:08:05AM +0930, Rusty Russell wrote:
> For HTLCs, this means:
> 1) Timeout returns for HTLCs A initiates must be OP_CSV delayed.
> 2) Payments for HTLCs A receives must be delayed.
>
> I just noticed the scripts in the 0.1 draft are a bit messed up; in
> particular they're missing a delay. Here's the (fixed!) A offers HTLC
> to B case:
Ah ok, cool!
> [scripts]
After thinking about this for a bit, there's two implications for this
script:
1. De-facto requires constantly watching the blockchain for a very low
interval. If Alice and Bob establish a channel, make a couple payments,
and now the balance of the channel is now 0 to Alice and 1 BTC to Bob,
if Bob doesn't constantly watch the chain, he can lose money. If the
HTLC-TIMEOUT is defined as 1 day, Alice can broadcast an old Commitment
and then hope Bob isn't paying attention and steal some money. In
effect, the maximum time between watching the chain will be the minimum
HTLC-TIMEOUT throughout the life of the channel when the channel balance
is currently tiled heavily in one direction.
2. Probably at the minimum doubles the HTLC timelock on LN payments. If
there is a minimum amount of time to wait to redeem funds (or receive a
refund), then the HTLC timeout must give you sufficient amount of time
to redeem as well. I suspect the amount of time necessary is about the
same since they're both dependent upon the estimated amount of time to
enter into the blockchain. If that's the case, doubling the HTLC
timeouts has some implications since it'll result in higher fees as a
downside, but might bias towards less graph centralization as well.
Fundamentally, the cause is derived from the fact that the HTLC timeout
and the OP_CSV revocation are inextricably linked.
Number 1 is more relevant to me (IMO), which is why I brought up the
reserve thing. I'm not so into the reserve balance concept, simply
because it severely limits the amount of transactional flow available at
once (it also limits the number of retries/multiplexing sends), which
matters more for liquidity providers (that model can reduce available
liquidity by 4x in best-case scenarios).
--
Joseph Poon

2023-06-09 12:43:46

- reply

📅 Original date posted:2015-07-26
📝 Original message:
On Sat, Jul 25, 2015 at 10:59:16PM +0200, Christopher Jamthagen wrote:
> <div>According to the whitepaper: " If three days have elapsed,
> then the above clause is null and void and the clearing process is
> invalidated, both parties must not attempt to settle and claim payment
> after three days." But clearly there is nothing stopping Bob from
> taking the HTLC output when Alice is forced to broadcast the
> commitment transaction, even if it is supposed to be null and
> void.</div>
Hi Christopher,
The design of the HTLCs have a contestation period built-in where the
party which broadcasts the Commitment Transaction must wait a period of
time before the payment goes back to themselves.
I think your concern may have some implications for Rusty's dual
anchor/funding version. I had incorrectly stated that it might be
possible to do it only with OP_CLTV, but it clearly requires both
OP_CLTV and OP_CSV.
There's more information being attested when relying on OP_CSV for the
HTLC without a transaction chained 2 levels deep. It will require
greater time delay between each hop in the payment to account for the
relative time to prove whether the Commitment has been revoked. This
greater time creates a tradeoff which requires each channel participant
(for every hop) to watch the blockchain at a more frequent interval,
since that OP_CSV value is intrinsically linked to the payment.
With a SIGHASH_NOINPUT (or similar) model having transactions two-deep,
this contestation period can be independent of the actual HTLC payments.
In effect, the first transaction spending from the HTLC validates
whether the preimages are known, the second is whether the Commitment
itself is invalidated. With separated anchor/funding, those two steps
are combined inside the Commitment Transaction -- AFAIK, (minus the
above tradeoffs) it still works though, but I'll double-check.
--
Joseph Poon

2023-06-09 12:43:46

- reply

📅 Original date posted:2015-07-27
📝 Original message:
On Mon, Jul 27, 2015 at 11:20:54AM +0930, Rusty Russell wrote:
> Yes, I assume that the HTLC gets eliminated by a commitment transaction
> update at (or before) that time.
>
> We could add an additional delay for this case, but it seems like
> overengineering?
To ensure that the older version of the transaction does not get
broadcast through a credible threat, there needs to be some contestation
period for one's own HTLC when one is redeeming funds.
However, there are less elegant solutions that are possible as a
stop-gap before a full malleability fix which permits you to generate
child transactions before signing the parent.
Current/unexpired HTLCs will have the same payout and enforcement, but
there is a risk of broadcasting older Commitments and stealing the HTLC
payout, e.g. transactions that are believed to be timed out but whose
preimages are known after-the-fact. Theft of the HTLC via broadcast of
expired Commitments can be mitigated by having some funds in reserve
available on one's own channel balance to ensure honesty. In effect, the
total value of the HTLCs must be below one's own reserve balance (for
both parties). The reserve balance must not be used ever.
Note that this presumes dual-funder. I'll go into single-funder model
later.
For example, if Alice and Bob have a channel with the latest Commitment:
0.49 to Alice (0.02 in permanent reserve)
0.50 to Bob (0.02 in permanent reserve)
0.01 HTLC Alice to Bob
This is a valid HTLC, since Alice's current channel balance not
allocated to HTLCs is 0.49. This balance must be at or above 0.02 at
all times throughout the life of the channel, until Alice closes it out
or does a final payment to zero it out and close. Similarly, Bob also
must maintain a balance of 0.02 throughout the life of the channel.
The sum of all HTLCs going from Alice to Bob must be at or (preferably)
below this 0.02 limit at all times before closing out the channel.
The result is if Alice broadcasts an old Commitment, Bob is assured that
the balance of the HTLC will be at or below 0.02. The maximum Alice can
send will be 0.98 in the channel, so even if she attempts to steal the
HTLC, Bob can be made whole by taking back all his funds, as well as all
of Alice's funds as penalty. Even if he is unable to take back the HTLC,
he will take all of Alice's funds in reserve, which is less than the
balance of all HTLCs in transit from Alice to Bob at all times
throughout the historical life of the channel.
Depending on how willing you are to enforce the HTLC past this point,
you can make the script substantially simpler, as well.
To fund this using single-funder, one should be very cognizant of risks
related to systemic risks related to trust asymmetry of the channel
counterparties. If we construct a model using single-funder, it requires
very shallow rebalancing of funding for symmetric trust, i.e. Alice
opens a channel to Bob first, then Bob opens a channel to Alice. This
initial channel funding would probably have a very high OP_CSV value.
For the OP_CSV value to be this high and functional without DoS risks,
it requires the number of LN hops to be fairly low during this channel
setup phase (but won't matter after), as they may be potentially locking
up money for a longer period of time if the HTLC payment is not
fulfilled). For OP_CLTV only (without OP_CSV) I think it'll be to the
point where it *requires* setting up two channels with the same person.
Personally, I have some reservations for models which have funds in
permanent reserve, but this model is a fairly good stop-gap before a
real malleability fix (SIGHASH_NOINPUT or segregated witness). This
model should be able to work with just OP_CLTV (and with OP_CSV too),
but may not be quite as fun. Also, to maximize fun under this model to
mitigate when a counteparty is a jerk, you should always make sure the
amount in permanent reserve is *always above* (not equal to) the value
encumbered in HTLCs.
--
Joseph Poon

2023-06-09 12:43:45

- reply

📅 Original date posted:2015-07-27
📝 Original message:
Hi Anthony,
On Sat, Jul 25, 2015 at 06:44:26PM +1000, Anthony Towns wrote:
> On Fri, Jul 24, 2015 at 04:24:49PM -0700, Joseph Poon wrote:
> > Ah sorry, that only solves the Commitment Transactions, not the HTLC
> > outputs. It's also not possible to use the pubkeys as identifiers,
> > as Rusty said, P2SH would be used.
> >
> > While it's possible to only check only recent blocks before the
> > Commitment Transaction for the search space (e.g. 3 days worth),
> > since you know when the Commitment Transaction was broadcast, the
> > search space limitation sort of breaks down if you permit long-dated
> > HTLCs.
>
> I don't think it matters how long the HTLC was; maybe they're way old
> and all expired, but were payments to you. Say the current channel is:
>
> 12 -> Cheater 88 -> You
>
> and the old transaction that Cheater just pushed to the blockchain
> was:
>
> 55 -> Cheater 3 -> You 10 -> You & R1 | Cheater & Timeout1 20 -> You
> & R2 | Cheater & Timeout2 12 -> You & R3 | Cheater & Timeout3
>
> To get at least your 88 owed, you need all but the last transaction,
> so you need to be able to workout #R1 and #R2 and Timeout1 and
> Timeout2, no matter how long ago they were.
Yes, I agree, that is absolutely true. I was alluding to something
different (but didn't properly explain myself), which is that if you did
grinding of only recent Commitments, it's possible that there will be
HTLCs with very high timeouts in the future and this may be a necessary
requirement for some possible future use cases (e.g.
recurring/pre-allocated billing).
> > For now, I think a reasonable stop-gap solution would be to have
> > some small storage of prior commitment transactions. For every
> > commitment, and each HTLC output, store the timeout and the original
> > Commitment Transaction height when the HTLC was first made.
>
> I don't think you want to multiply each HTLC output by every
> commitment it's stored in -- if the TIMEOUT is on the order of a day,
> and the channel is updated just once a second that's a x86,400 blowout
> in storage, so almost 5 orders of magnitude.
>
> But if everytime you see a new HTLC output (ie, R4, Timeout4), you
> could store those values and use the nLockTime trick to store the
> height of your HTLC storage. Then you just have to search back down
> from R4 to find the other HTLCs in the txn, ie R3, R2 and R1, which is
> just a matter of pulling out the values R, Timeout, dropping them into
> payment script templates, and checking if they match.
Yes, that's a good point(!), especially when you're doing local storage.
If you're relying on OP_RETURN, though, you must put in some more
contextual data. If you're willing to regenerate the revocation hash
every time, I guess the OP_RETURN can just be timeout and H. For local
storage, you don't need to do it for every HTLC if you're willing to
search back on near-dated HTLCs, but long-dated HTLCs (say, greater than
a couple days) could be included (class memory vs. computation
tradeoff). Agreed, the necessary data storage isn't *that bad* for core
nodes, and trivial for edge nodes not doing liquidity providing
(ignoring backup concerns, of course).
> BTW, 10 commitments per second (per channel) doesn't sound /that/ high
> volume :) Pay per megabyte for an end user at 100Mb/s is already
> around that at least at peak times, eg.
Perhaps with a relatively distributed graph and core nodes having many
connections, it's possible that's the range. Either way, it should be
fine. If you have enough entropy to filter by hundreds of millions using
nLockTime, even if you have 10 billion (or 100 billion) to search
through it should be nearly instant. If you have 1000 possible
revocation hashes, just look at the first txout (the non-HTLC payouts to
Alice and Bob) and see which revocation fits. Once you know the exact
Commitment number, the rest of the outputs are easy.
--
Joseph Poon

2023-06-09 12:43:44

- reply

📅 Original date posted:2015-07-24
📝 Original message:
Ah sorry, that only solves the Commitment Transactions, not the HTLC
outputs. It's also not possible to use the pubkeys as identifiers, as
Rusty said, P2SH would be used.
While it's possible to only check only recent blocks before the
Commitment Transaction for the search space (e.g. 3 days worth), since
you know when the Commitment Transaction was broadcast, the search space
limitation sort of breaks down if you permit long-dated HTLCs.
Worst-case it may be possible to have long-dated HTLCs on a seperate
hash-tree, but it's not an ideal solution.
In retrospect, this P2SH problem is somewhat exacerbated by the fact
that the timeout being different numbers as well, so ideally that should
be stored as part of the output. The tradeoff between having the entire
script in the output (which results in larger transactions), and using
P2SH (which reduces bits of entropy/identifiability) is a bit of a
problem. For some reason, I've always assumed the output would be
included (ignoring isStandard issues), but that may not be optimal.
For now, I think a reasonable stop-gap solution would be to have some
small storage of prior commitment transactions. For every commitment,
and each HTLC output, store the timeout and the original Commitment
Transaction height when the HTLC was first made. That should be enough
information to work with (you can work backwards if you know which
Commitment Transaction the HTLC was first created) and amounts to 48
bits (6 bytes) of storage per HTLC output per fully expired Commitment
Transaction. I generally dislike OP_RETURN as a solution, but it's
possible.
Thanks for bringing this up, I haven't really properly considered this!
--
Joseph Poon

2023-06-09 12:43:44

- reply

📅 Original date posted:2015-07-24
📝 Original message:
Oh, I forgot it's necessary to store the hash of the R value. That'll
make it much bigger. 26-bytes or so.
Also, if OP_RETURN is viewed as acceptable, then you should be able to
fit 3 outputs per OP_RETURN metadata output.
Thinking through further, using OP_RETURN metadata is objectively better
than just having the nonstandard non-P2SH output when considering
transaction size.
So for OP_RETURN, you could have a blob up to 80 bytes (or 40 if you
want to maximize relay), which results in ~3 transactions if you assume
26-bytes per transaction. If you have a lot, you should probably just
fill it all up and compact it, I guess.
16-bits is fine for timeouts since that's 65535 block heights, which is
a little over a year's worth. Nothing's stopping you from supporting
more than a year's worth if you can find the route, but that's a fine
upper-bound for now.
32-bits is used for the Commitment Transaction. For even the most
high-volume node, 10 commitments per second results in 300 million
Commitment Transactions. This identifies in which Commitment Transaction
the HTLC was created. By knowing the Commitment Transaction, you'll know
the revocation preimage, so after the revocation information has been
exchanged, you only need to know which Commitment Transaction the HTLC
was originally formed, since the revocation information was originally
*generated* using a merkle tree derived from the Commitment Transaction
as an index.
In total that's 48-bits (6bytes) per HTLC output per Commitment. Plus
20-bytes for the hash(R), 26bytes.
If someone broadcasts an old Commitment and you don't have the HTLC data
because it's expired and too old, check the OP_RETURN data for the
6-bytes, then compute the revocation data and compute a couple hundred
revocations and see which one fits.
I think the tradeoff might be worth it. If you stored this data locally,
the cost shouldn't be too high for end-users. However, for those that
wish to do a lot of routing, this can add up. A node that does 10
commits/s with 100 HTLCs on average that results in a little over 800GB
of local storage per channel if OP_RETURN wasn't used, which may very
well be feasible for large hubs. Of course, whether OP_RETURN or local
storage were used, it's better than having the entire script as part of
the output.
--
Joseph Poon

2023-06-09 12:43:44

- reply

📅 Original date posted:2015-07-24
📝 Original message:
Hi Anthony,
If we're presuming everyone uses OP_CSV in the long-term, you can
overload nLockTime with values below current unixtime as a
filter/counter. It should be enough bits of entropy no matter the size
(even in the billions of transactions in a single channel) Since both
parties are signing the nLockTime value, it's safe to use that as an
identifier in the Commitment Transaction.
--
Joseph Poon

2023-06-09 12:43:40

- reply

📅 Original date posted:2015-07-17
📝 Original message:
On Fri, Jul 17, 2015 at 05:49:15PM +0930, Rusty Russell wrote:
> http://ozlabs.org/~rusty/ln-deploy-draft-01.pdf
Very cool!! The proposed construction with OP_CHECKLOCKTIMEVERIFY and
OP_CHECKSEQUENCEVERIFY may make lightning be deployed *much* sooner.
Rusty's idea is fantastic and goes very far in creating a usable way to
really try out lightning on Bitcoin.
I'll have an update of my paper incorporating these changes, they're
really significant.
(Current version, will incorporate the above changes very soon:
http://lightning.network/lightning-network-paper-0.5.9.pdf )
--
Joseph Poon

2023-06-09 12:43:38

- reply

📅 Original date posted:2015-07-13
📝 Original message:
On Tue, Jul 07, 2015 at 03:39:39PM +0930, Rusty Russell wrote:
> Feedback, optimizations, horrible holes?
I think this model works! As soon as OP_CHECKLOCKTIMEVERIFY soft-forks
into bitcoin, a basic lightning implementation may be theoretically
possible in real bitcoin (with some significant caveats)!
I think Thaddeus Dryja came up with a similar implementation to resolve
malleability in multisig (involving a clock and 2-input/2-output).
However, I think a true malleability fix is still ideal.
To complete the thought, I think it's possible to make the Commitment
Transactions malleability-safe under this construction.
> The order is as follows:
>
> 1) We both trade anchor txids and amounts.
> 2) We both trade signatures for the escape transactions, so either one
> can broadcast them.
> 3) Now we are sure to be able to recover our funds, we each broadcast
> our anchor txs.
> 4) If the other side broadcasts their escape transaction, abort and
> broadcast our escape transaction. After the timeout, we can spend
> it.
> 5) If the other side doesn't broadcast their anchor tx, abort and
> broadcast our escape transaction.
> 6) Otherwise, when the anchor txs reach the required depth, we exchange
> signatures for the commitment transaction.
> 7) If the other side broadcasts either escape transaction, broadcast
> the other escape transaction and the commitment tx as normal (this is
> a unilateral close) before they can reclaim their anchor funds.
To create the Commitment Transaction (in step 6 and all future
Commitment Transactions), it requires spending from the two inputs
separately and the output would require having OP_CLTV or OP_CSV in the
script output to determine whether a Commitment has been revoked. This
is necessary since one cannot be fully confident about the Transaction
ID beforehand.
If the inputs are 0.5 Alice and 0.5 Bob, the first Commitment
Transaction would refund 0.5 to Alice and 0.5 to Bob. As always, there
are a pair of Commitment Transactions per commitment state. Presume the
current block height is 350,000 and the channel closes at 355,760.
The Commitment Transaction which only Alice can broadcast, Commitment
1a, would have the following outputs:
0. 0.5 BTC
BobKey
1. 0.5 BTC
OP_IF
<AlicePubKey> OP_CHECKSIGVERIFY
<355,760> OP_CLTV OP_DROP
OP_ELSE
OP_HASH160 <RevocationHash> OP_EQUALVERIFY
<BobPubKey> OP_CHECKSIGVERIFY
OP_END
This is the general idea at least (haven't checked the script). Bob gets
all his money if Alice broadcasts it immediately because Alice is
attesting Bob should get *at least* 0.5 BTC. For the second output
(output 1), the first path gives Alice the funds at channel expiration.
The second path is so if the current Commitment transaction is not
Commitment 1 and Alice should lose all her money for incorrectly
broadcasting Commitment 1. Alice does this by attesting to Bob she
wouldn't broadcast Commitment 1 by giving the RevocationPreimage which
is hashed into RevocationHash.
Bob also has a Commitment Transaction which is the opposite (Alice's
funds get paid immediately, Bob's funds is encumbered by time).
The purpose of doing this type of construction instead of using
nLockTime on the transactions spending from the Commitment Transaction
is so that each output only requires one signature. By having only one
signature, malleability concerns can be mitigated, since that single
party can simply resign and is not dependent upon the cooperation of the
counterparty if the Commitment Transaction itself gets mutated. Since
the Commitment Transaction is only build after the Anchor and Escape
transactions exist, then this construction will allow for Lightning
Network channels to exist with OP_CLTV, with the caveat that with
uncooperative counterparties, you will have to wait until channel
expiration to get your money back. However, it does mean that playing
with LN is a possibility on the real bitcoin chain in the near future.
Very cool, Rusty!
--
Joseph Poon

2023-06-09 12:43:34

- reply

📅 Original date posted:2015-07-15
📝 Original message:
On Wed, Jul 15, 2015 at 11:51:06AM +0930, Rusty Russell wrote:
> Perhaps we can rig something that requires the recipient to pay more
> according to time?
>
> Joseph?
It's definitely possible, depends on what kind of complexity you're
comfortable with. I think Tadge brought up the idea a long time ago
about using the timelock for decay of payments with one's counterparty
for on-chain enforceability. E.g. A current Commitment has 50
sub-commitments which pay out different lightning fee values with later
locktimes.
Presume an HTLC has a 0.09 value with 0.01 allocated to fees (refunds
back to Alice any extra fees). If we are currently at Commitment #123,
we have Commitment123_1, Commitment123_2, and Commitment123_3. Each have
very similar payouts, with very minor differences in HTLC fees paid and
the locktime.
Assuming some kind of full on-chain Replace-By-Fee, you
can prioritize Commitment123_3 over Commitment123_2 on-chain, but
Commitment123_3 will also have a higher fee on lightning as well.
However, Commitment123_3 can only be broadcast at a later date, so
"earlier" Commitment123 values can be valid. Things can get a little
wonky at the edges, so you have to arrange the fees such that if there's
some time asynchronousness along the chain, that intermediary nodes
don't lose out (functionally I think this means the time-decay will be
somewhat marginal and be a small percentage of the total lightning fees
paid).
--
Joseph Poon

2023-06-09 12:43:31

- reply

📅 Original date posted:2015-07-02
📝 Original message:
Hi Rusty and Stephen,
On Tue, Jun 30, 2015 at 05:33:00PM +0930, Rusty Russell wrote:
> Joseph's solution is that E can route a conditional refund back to A
> with a larger timeout (say 3 days) via some other route: this pays
> back the amount to A if they present the preimage for the initial
> stalled payment and another preimage A only has. This serves as a
> guarantee that E will not reveal the preimage required to take the
> stalled payment.
To clarify, this is only necessary if there is a routing failure when a
signed transaction has been sent but not acknowledged or cancellation is
refused.
For example, presume the prior route A->B->C->E. If C acknowledges B's
attempt to route but does not actually route after the signature has
been sent by B to C, then A and B are unsure whether C's computer has
gone offline or is acting maliciously. In that case, it's necessary for
E to send a "conditional refund" back to A. The reason A requires an
additional preimage/hash when doing the "conditional refund" is in case
the conditional refund itself fails.
However, the most likely case is the routing fails cleanly. If B is
unable to send to C because C has been offline or B otherwise refuses to
route to C, B can undo the HTLC by cancelling the HTLC entirely
(replacement with a new Commitment transaction state with A). This
cancellation can cascade back to the sender to free up the money. In the
event that the cancellation doesn't end up cascading back to the sender
(should be fairly rare), then A can get E to do the same E->D->A with
the same hash described in the previous example. Most routing failures
should end up being rollbacks.
> This raises other questions, such as who would pay E (and any other
> intermediate nodes) for locking up their money for such a time. Could
> A provide evidence that the route really had timed out? How many
> times can A claim "payment failed"? etc.
I'm assuming that the payment from A to E is split into many small
payments. If the payment is too small to be split up, then it's probably
cheap enough to not matter anyway (in most cases, waiting for expiration
is no big deal). Resolving incomplete payments should be deferred until
after the payment is sufficiently complete; E can have as a policy to
only send "conditional refunds" when she has received sufficient funds
from A (and A has paid for the time-value/fee of the refund). Since the
payment is likely source-routed, it is the responsibility for the sender
to pay for payment failure. The incentives are largely in favor of
receiver being online and accepting -- the recipient, is after all,
increasing the amount of bitcoin they own.
--
Joseph Poon

2023-06-07 17:59:16

- reply

📅 Original date posted:2017-04-05
📝 Original message:Hi Greg,
On Wed, Apr 05, 2017 at 09:37:45PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
>
> On that basis, I offer the following BIP draft for discussion.
> This proposal does not prevent the attack in general, but only
> inhibits covert forms of it which are incompatible with
> improvements to the Bitcoin protocol.
>
> I hope that even those of us who would strongly prefer that
> ASICBOOST be blocked completely can come together to support
> a protective measure that separates concerns by inhibiting
> the covert use of it that potentially blocks protocol improvements.
>
> [...]
>
> ==New consensus rule==
>
> Beginning block X and until block Y the coinbase transaction of
> each block MUST either contain a BIP-141 segwit commitment or a
> correct WTXID commitment with ID 0xaa21a9ef.
>
> (See BIP-141 "Commitment structure" for details)
>
> Existing segwit using miners are automatically compatible with
> this proposal. Non-segwit miners can become compatible by simply
> including an additional output matching a default commitment
> value returned as part of getblocktemplate.
>
> Miners SHOULD NOT automatically discontinue the commitment
> at the expiration height.
Decentralized systems without patent encumbrance is an important topic
for me. We'd be very interested in adding this into extension blocks.
Claims like these merit serious attention. If you can provide any kind
of proof or documentation of this (doesn't need to be conclusive, just
something), I will provide my word and promise publicly here and now
that I will personally see to it that a commitment which solves this
(albeit possibly using a slightly different format to make it
compatible) is added into the Extension Blocks spec. If there is
evidence, my support and authorship of the Extension Block specification
is contingent upon resolving this issue.
We have added an issue here:
https://github.com/tothemoon-org/extension-blocks/issues/6
I'm interested in a more detailed explanation on how the Merle tree
structure works so we can add it to the spec, I didn't follow exactly
the new consensus rule and its mechanism in those several lines.
We will begin making a pull request adding it into our specification,
but more clarity on how to do it on its own would be helpful. We will
also consider the code exposure change to adding in SegWit on the
Canonical/1MB chain if it is more elegant to implement.
Packaging this into our proposal would not only be important, but
helpful to the end goals of this proposal as it becomes a standard
soft-fork consensus rule which has greater guarantees around
enforcibility than user-actication.
Further, can you provide clarity and confirmation into why this
commitment wasn't required as part of SegWit?
--
Joseph Poon

2023-06-07 17:59:15

- reply

📅 Original date posted:2017-04-05
📝 Original message:Ahh, sorry all for this public message. :(
On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote:
> #bitcoin at freenode:
> 00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
>
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking you seriously and having second thoughts and want to make public
> commitments to do the right thing without any evidence and you come out
> and say *this*?
--
Joseph Poon

2023-06-07 17:59:15

- reply

📅 Original date posted:2017-04-05
📝 Original message:On Thu, Apr 06, 2017 at 01:32:03AM +0000, Gregory Maxwell wrote:
> On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon <joseph at lightning.network> wrote:
> > #bitcoin at freenode:
> > 00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
> >
> > Are you *fucking* serious? Is this how you resolve all problems? I'm
> > taking you seriously and having second thoughts and want to make public
> > commitments to do the right thing without any evidence and you come out
> > and say *this*?
Apologies to the list.
> I apologize for the glib talk on chat and I hope you understand that
> the tone in such venues is significantly informal; and that my remark
> was a causal one among friends which was not intended in a spirit as
> seriously as you've taken it.
You're still presuming ill-will. I'm seriously offended. I'm not upset
with the glib talk, I'm upset that you think I have ill will.
> That said, two days ago you participated in a highly unusual
> announcement of a protocol change that-- rather than being sent for
> community review in any plausible venue for that purpose-- was
> announced as a done deal in embargoed media announcements. This
> proposed protocol change seemed custom tailored to preserve covert
> boosting, and incorporated direct support for lightning -- and the
> leading competing theory was that a large miner opposed segwit
> specifically because they wanted to block lightning. Moreover, I have
> heard reports I consider reliable that this work was funded by the
> miner in question.
We specifically told you guys privately and publicly when asked that it
was simply to be able to do it in 2 weeks. Check out the code, it was
much faster to do it that way. The spec wasn't complete and I have
personal biases against doing it on the main-chain since it would
benefit things if there was smart contract proections on the main chain
as well, which I figured would be more controversial. I never said
anything about public commitments to transactions. In fact, I'm pretty
good at figuring things out and tend to cargo-cult things (since culture
is the genetic memory is civlizations), if I saw BIP141/SegWit required
a commitment instead of it being optional, I would've probably thought
about it. Why wasn't this required as part of SegWit? BIP141 is still
vulnerable. Why did you pull this out just now? I'm totally blindsided
here, hence my earlier reply of wanting to resolve it in the Extension
Block proposal.
> In the time since, when people asked for revisions to the proposal to
> not block segwit they received responses from the Bcoin account on
> twitter that "there would be no amendments", and I was sent leaked
> chatlogs of you making considerably hostile statements, claiming that
> if your extension block proposal is "a litmus test for corruption",
> and claimed (before AFAIK anyone had had a chance to comment on it)
> that the Bitcoin project contributors opposed it for "nonsense
> reasons".
I never participated in that, and the specific announcement here
indicates that changes will be happening. The intention was to get it
out as a draft and *working* demo code.
https://medium.com/purse-essays/ready-for-liftoff-a5533f4de0b6
That was specifically after Core developers accused me of publicly
acting in poor form without any understanding of the situation. I was
especially annoyed because all of you are acting with similar secrecy,
even worse, there is specific organization by Core which the public is
not aware of. Think about it from my perspective, you all blocked me out
intentionally for months and then accuse me of going to journalists for
a couple hours before? I'm seriously hurt.
> It is with this in mind that when you tried to pull me into an off the
> record conversation that I responded stating:
>
> "[...] I am disinclined to communicate with you except in email where I can
> get third party transferable proof of our communication. I'm
> concerned that you may now be involved in a conspiracy which I do not
> want to be implicated in myself.
>
> It is my estimation that, for that above reason, it would be in my
> best interest to not communicate with you at all. But in all your
> prior interactions you appeared to have integrity and sense, so out of
> respect for that history I'm willing to communicate with you, but only
> in public or in email where my end is on gmail."
Nice you cut out the beginning which explains on *why* I didn't reply:
"with an embargoed press release in Forbes.
That's how you roll now, right? :-/"
Why didn't you include your entire message?
That was in reply to my initial message reaching out to you and Adam
Back:
"Hi, would you like a phone call tomorrow?
I am in Thailand right now, I understand if what I did is upsetting, my
goal was not to upset you.
I deeply respect you both technically, but I do believe what I am doing
is right. If you could find a way, I would be extremely grateful if we
could chat sometime."
Replying with a beginning like that with that kind of hostility means I
sort of don't know how to reply! Further, you didn't express any real
concerns to me. I just figured you were mad and wanted to give you time
to cool off. Calling someone up is a way to explain over a higher
bandwidth medium gives material reiteration of a real honest heartfelt
apology in misunderstanding.
> This was two days ago and you did not respond further.
>
> With that in mind I hope you do not find some casual crap-talking on
> chat to be especially surprising.
>
> I understand that you didn't intend for the initial message to be
> posted in public, so I'm sorry for continuing the thread here-- but I
> thought it was useful for people to understand the context behind that
> glib remark: Including the point that I do not know for a fact that
> you are complicit in anything, but I consider your recent actions to
> be highly concerning.
I'm only including more details in the email because you had deceptive
framing. I normally would *never* include contents in a private email
message and believe this is already the gray area. I already feel
uncomfortable publishing my message to you without permission, but I
feel it's necessary context, but I will not continue. Would you like to
have a public call instead? I really want to talk to you to express that
I really mean what's best for bitcoin. I've had a sleepless night
thinking about these things, this type of drama is *NOT* good for
bitcoin.
I came here with good intent, even with Core and Blockstream being
outright hostile and controlling with many personal problems over the
years which I have never aired previously. I can tell when I'm not
welcome. I'm going to take a break from all of this.
--
Joseph Poon

2023-06-07 17:59:14

- reply

📅 Original date posted:2017-04-05
📝 Original message:#bitcoin at freenode:
00:04 gmaxwell| lol poon pretending that he isn't complicit in all this stuff.
Are you *fucking* serious? Is this how you resolve all problems? I'm
taking you seriously and having second thoughts and want to make public
commitments to do the right thing without any evidence and you come out
and say *this*?
On Thu, Apr 06, 2017 at 12:17:17AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > This seems to be a serious security problem. Would it be possible to have
> > a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger
> > 3-6 months from release should be sufficient for enough of the economy to upgrade,
> > given the severity of the issue.
>
> Not 0.14.1 because that is in RC already and will hopefully be out in a week.
>
> I think the speed of adoption depends a lot of the level of support
> from the community. I don't believe there are any technical hurdles to
> implementing this relatively quickly (and I specifically propose using
> the users choice of the segwit commitment or a modified form in order
> to lower the technical complexity and risk).
>
> > BIP 141 says that the the commitment is optional if there are no SegWit transactions in
> > the block, so will today's SegWit-ready miners always produce it even when optional
> > according to BIP 141, as required by this softfork?
>
> This is the default behavior as of 0.13.2, but I haven't gone out to
> measure this which is why the backwards compatibility section of the
> BIP isn't written yet.
>
>
> While I'm posting, I've had a dozen off-list emails that presented me
> with some FAQ:
>
> Many people asked what other protocol upgrades beyond segwit could run
> into the same incompatibility.
>
> Many proposed improvements to Bitcoin require additional
> transaction-dependent commitment data.
>
> Examples include:
>
> (1) Segwit.
> (2) UTXO commitments. (non-delayed, at least)
> (3) Committed Bloom filters
> (4) Committed address indexes
> (5) STXO commitments (non-delayed).
> (6) Weak blocks
> (7) Most kinds of fraud proofs
> -- to state a few.
>
> Unfortunately, putting *any* commitment to data dependent on the right
> hand side of the hash tree in the left hand side (e.g. coinbase) means
> a massive increase in the computation required for covert boosting,
> because it means you can't use the left+right side combinations to
> eliminate most of the hashing.
>
> It's plausible, in fact, that this extra computation could completely
> nullify the ASICBOOST advantage-- though this depends a lot on the
> fine details of the implementation.
>
> This proposal does not itself propose nullifying ASICBOOST entirely,
> it proposes severely handicapping the covert form of it, and
> eliminating the differential advantage for boosting miners related to
> the use of transaction-dependent commitments.
>
> Basically there are two completely separate concerns: that boosting
> can produce a monopoly advantage which could be severely harmful to
> the ecosystem, and that the efficient implementation of _covert_
> boosting can severely harm many useful protocol improvements. My
> proposal only addresses the second concern, by (I believe) completely
> leveling the playing field so that opposing commitments will not break
> boosting any worse, and by making covert boosting less appealing in
> general.
>
> Use of the segwit-style commitment even in non-segwit blocks is sufficient
> because the segwit commitment commits to all transactions (except
> the coinbase) and not just segwit ones.
> (It was designed this way so that lite clients that needed witness
> data could work with just one tree).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Joseph Poon

2023-06-07 17:59:06

- reply

📅 Original date posted:2017-04-05
📝 Original message:On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote:
> I'd appreciate the authors chiming in, but I read the PASDA differently:
>
> 1) If a transaction is mined with a certain bit set, it reserves 700 bytes
> for that particular block.
> 2) In that space, 2 transactions may happen:
> a) First, a transaction penalizing the "parent" transaction for fraud by
> spending the funds immediately
> b) Second, a "free rider" transaction that penalizes fraud within a ~2 week
> window
>
> This means during systematic flooding of closing transactions by
> Goldfinger, vigilant watchers of their channels can immediately punish the
> fraud in the same block using (a), and if they are unable to, need to find
> space within two weeks in (b).
>
> This is really in the LN weeds however, so I'll refrain from evaluating the
> efficacy of such a solution.
Yes, that is correct. I haven't had a chance to review Laolu's summary
yet, haven't had a chance to talk to him today since I was away from the
keyboard for most of the day, would have been unable to review things.
Section "b" above only allows for free riding on the first output of a
transaction with the bit set within the past 2016 blocks. It does not
allow free riding on outputs without that bit set in the transaction.
Additionally, the presumption is that the attacker fills up the
mempool with incorrect prior commitment transactions.
The attack scenario is Mallory asks everyone to open a channel with her.
Mallory only has 1 BTC. With sufficiently low tx fees, Mallory can use
that one bitcoin to open many ~1 BTC channels. All of those channels had
a prior state which Mallory had ~1 BTC, and a current state where she
has none. She broadcasts these thousands of prior states where she has
~1 BTC.
The presumption is the penalty transaction in many cases has a very
small fee, since it is already covered by the commitment.
This mitigates systemic goldfinger attacks since it is unlikely they can
get enough transactions in. Additionally the transactions waiting on the
mempool allows for many to be notified and fill up the first reserved
space. The attacker would likely be attempting to fill up the mempool
(longer block times help here with security!!!). It is presumed that
there is some small amount in reserve so there is some fee reward
covered for enforcing the penalty. This construction allows for the
amount in reserve to be significantly smaller and much more resilient
against even the largest of goldfinger attacks.
(This isn't a full mitigation, as there are certain conditions related
to miner-attacker coordination with high hashpower. Attacker-Miner
coordination is presumed to be out-of-scope, especially in relation to
51% attacks, since it's sort of a moot point, if they have the funds to
mount this attack so that it's profitable, it gets pretty close for them
to have a very significant hashpower anyway.)
I'll add a clarification to the specification on github soon. The intent
of this is to reduce the cost of setting up LN channels with funds in
reserve, with minimal code changes. Future changes which could be
desired if this is usable would be use additional tx flag bits to select
how many outputs in a transaction apply to enable a large payment of
funds pending in-flight.
--
Joseph Poon

2023-06-07 17:52:56

- reply

📅 Original date posted:2016-08-16
📝 Original message:I agree this is an interesting area of transaction malleability to still
consider in the future, and minimization of these areas of malleability
with regards to its impact on the p2p network should be easy to resolve
and (hopefully) well-understood by script writers in the future.
On Tue, Aug 16, 2016 at 12:43:32PM -0700, Peter Todd via bitcoin-dev wrote:
> Having said that, a better approach may be a separate CHECKBOOLVERIFY opcode
> that fails unless the top item on the stack is a minimally encoded true or
> false value, to allow script writers to opt into this behavior; it's not always
> ideal.
I think the biggest value of the proposed BIP behavior is that the cost
is lower for "doing it right" to create script enforcement of OP_TRUE or
OP_FALSE. It is already possible to enforce with 2 bytes pushing OP_TRUE
and then OP_EQUAL. Creating an "OP_CHECKBOOLVERIFY" definitely achieves
the same result, but at a 1-byte (insetad of 2-byte) cost to "do it
right", so there is the same incentive to save on the byte and push
potential DoS costs onto the network -- whereas enforcing OP_TRUE byte
in OP_IF would create costs for those who want to evaluate pushdata, so
that has to be explicitly opt-in from an optimization/convenience
standpoint.
--
Joseph Poon

2023-06-07 17:49:18

- reply

📅 Original date posted:2016-02-26
📝 Original message:Hi Bryan,
On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:
> Well if you are bothering to draft up a BIP about that SIGHASH flag,
> then perhaps also consider some other SIGHASH flag types as well while
> you are at it?
I'll take a look at those proposals when drafting the BIP. I think for
LN, there is a single clean way to achieve outsourcability, but may be
compatible with other arrangements. I'm somewhat averse to proposing too
much flexibility before there's clear use-cases, though. However, if
others do have uses/examples for other sighash flags, I'd be very
interested while drafting this BIP!
> FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
> http://gnusha.org/bitcoin-wizards/2015-04-07.log
Yeah, I think the nice thing about SegWit is that you resolve
malleability without worrying about replay attacks in the event of key
reuse. That's why I think it's only safe to do this new sighash type
inside segwit itself -- if you only wanted protection against
malleability you'd use segwit, and not touch this new sighash type
(you'd only use the new sighash flag if you actually need its features).
--
Joseph Poon

2023-06-07 17:49:17

- reply

📅 Original date posted:2016-02-25
📝 Original message:Hi Greg,
On Fri, Feb 26, 2016 at 01:32:34AM +0000, Gregory Maxwell wrote:
> I think to be successful we must be absolutely ruthless about changes
> that go in there beyond the absolute minimum needed for the safe
> deployment of segwit... so I think this should probably be constructed
> as a new segwit script type, and not a base feature.
Absolutely, I'd certainly be interested in this being the first
proof/example for the script upgrade mechanisms if it's not ideal for
this to be implemented as part of Segregated Witness itself.
> The reason for this is that if hardware wallets are forced to continue
> transferring input transactions to check fees or to use
> without-inputs, they may choose the latter and leave the users
> needlessly exposed to replay attacks.
Yes, I think it's necessary to include the fees as part of the
signature, which will also allow for wallets to not require downloading
the input transactions. However, it's necessary to not include the input
amount itself, as they may differ. SegWit itself is very nice in that it
prevents improperly designed wallets and services using the bitcoin RPC
from making mistakes, you can resolve malleability without compromises
-- I also think any proposed SIGHASH should ensure some measure of
safety from design error/shortcuts.
> The fact that without input commitments transactions are replayable is
> highly surprising to many developers... Personally, I'd even go so far
> as to name the flag SIGHASH_REPLAY_VULNERABLE. :)
That's a good point, choosing a scary name is probably very helpful.
Thanks, I'll clarify with a specific BIP soon.
--
Joseph Poon

2023-06-07 17:49:16

- reply

📅 Original date posted:2016-02-25
📝 Original message:As Segregated Witness will be merged soon as a solution for transaction
malleability, especially with multi-party adversarial signatures, there
may be an additional use case/functionality which is helpful for
Lightning Network and possibly other Bitcoin use cases. This requires a
new SIGHASH flag inside Segregated Witness which does not sign the input
txid/index.
Segwit is very helpful in resolving malleability in pretty much every
case which matters. It is especially helpful in having solid and safe
defaults for standard Bitcoin payments; it's very difficult to mess up
if you are writing code in conjunction with the Bitcoin RPC API.
However, it is very useful for LN if there is a certain level of
outsourcibility for transactions without this 3rd party taking on
onerous costs. In LN, there is a dispute resolution period established
to prevent the counterparty from attesting an incorrect channel state
(represented by broadcasting a timelocked transaction). In other words,
if someone in a channel broadcasts an incorrect state, the output can be
redeemed by a 3rd party (but this 3rd party is not a custodian, since
the output goes to the other party in the channel).
Ideally, a 3rd-party can be handed a transaction which can encompass all
prior states in a compact way. For currently-designed Segregated Witness
transactions, this requires storing all previous signatures, which can
become very costly if individuals to thousands of channel state updates
per day. This is very possible, as fees are near-zero, the value in
atomizing all payments to many transactions becomes viable (reducing
transaction/information costs). If individuals are doing tens of
thousands of transactions per day, and one presumes something like
70-bytes of data per Commitment state in the channel, it quickly becomes
infeasible to watch on behalf of many channels without material costs.
This is especially necessary because it is highly desirable to make
keeping track of these channels be very cheap, as it allows for more
participants to be watching on one's behalf (reducing the chance of a
3rd party fail to watch). Further, it may reduce the need to notify the
3rd party for every single channel Commitment state, instead only
providing the most recent one should provide sufficient information for
all prior states (since the signature will apply for any type of
transaction), making the only updated information the revocation
secret/preimage. Without this SIGHASH flag, every single state would
need to be contacted and updated with 3rd parties. With this SIGHASH
flag, one could instead delegate outsourcing when one's client goes
offline with a single message several hundred bytes in size,
encompassing all prior states.
Of course, while running a 24/7 full-node is encouraged, I suspect many
people will not want to do so at the current time, and it needs to be
functional for those who elect to be connected intermittently. This
requires outsourcing or watching on one's behalf.
This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
does not include as part of the signature, the outpoint being spent
(txid and index), nor the amount. It however, would include the spent
outpoint's script as part of the signature. Note that this is just a
SIGHASH flag, and the outpoints are still being included as part of the
txins (if they are mutated, the new txids can be updated by the wallet
without resigning). This allows for a signature to apply to anything
with that pubkey (therefore pubkeys with this flag should not be
reused). For safety, this only applies in SegWit transactions, as segwit
provides a sufficient malleability solution, there is no incentive to
improperly use this sighash flag as a roundabout way to resolve
malleability.
This helps with 3rd-party outsourcing for watching the blockchain, as
one can provide a signature (and the most recent hash-chain of
revocation preimages), which encompasses penalty transactions for all
prior states. Functionally, this allows for opt-in wildcard inputs, but
wallets which do not require these transactions do not need to be
concerned with this flag; since they will never be signing with this
flag, they do not need to be concerned with address re-use.
I'm interested in input and in the level of receptiveness to this. If
there is interest, I'll write up a draft BIP in the next couple days.
--
Joseph Poon

2023-06-07 17:42:32

- reply

📅 Original date posted:2015-10-06
📝 Original message:Hi Peter,
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
Lightning network needs RCLTV for bidireciontal payment channels without
an explicit expiration date. Without a relative locktime, there is an
economic tradeoff between longer channel expiry dates due to lower fees,
and the time-value delay for non-cooperation. Due to this tradeoff,
there is a risk that people may create channels with entities which they
believe will be around in the future and act in a particular way. In
other words, it is possible that people will attach reputation as part
of their decision-making for channel creation.
> 2) Additionally to RCLTV, we need to implement this via nSequence
>
> However I don't think we've done a good job showing why we need to
> implement this feature via nSequence. BIP68 describes the new nSequence
> semantics, and gives the rational for them as being a
> "Consensus-enforced tx replacement" mechanism, with a bidirectional
> payment channel as an example of this in action. However, the
> bidirectional payment channel concept itself can be easily implemented
> with CLTV alone. There is a small drawback in that the initial
> transaction could be delayed, reducing the overall time the channel
> exists, but the protocol already assumes that transactions can be
> reliably confirmed within a day - significantly less than the proposed
> 30 days duration of the channel. That example alone I don't think
> justifies a fairly complex soft-fork that limits future upgrades; we
> need more justification.
The examples (including for Lightning Network) in BIP 112 provides a
rationale for using a relative locktime which cannot be achieved using
CLTV/hard-nLocktime alone. Without BIP 112, I agree the example in BIP
68 can also be done with nLocktime, but I think they sort of go
together?
However, there are some advantages to using some kind of relative
locktime field such as nSequence over purely a script opcode. This is
especially useful if one presumes some kind of long-term malleability
fix which does not include directly signing the TXID of the parent
transaction. It allows one to update dependent spending transactions
after-the-fact; after transactions are signed. If there are
unbroadcasted 2-of-2 multisig output transactions, where Tx1 is
confirmed on-chain and off-chain Tx2 spends from Tx1, they can elect to
spend Tx3a from the output of Tx2. Tx3a can have an nSequence value
which requires a minimum of 100 block confirmations of Tx2 to elapse
before Tx3a can be broadcast. As neither Tx2 or Tx3a have yet broadcast,
they can elect to double-spend Tx2 with a new transaction with a lower
nSequence value, e.g. Tx3b. This is important, as Tx2 will *always* be
spendable so creating new revocation rules is useful for Tx2.
I think Mark had once described the general idea is to have a similar
separation of the opcode and the actual validation of block height in
the codebase as nLockTime/OP_CLTV, as having pure validation in the
script which may make things a bit ugly.
> So, what else can the community come up with? nSequence itself exists
> because of a failed feature that turned out to not work as intended;
> it'd be a shame to make that kind of mistake again, so let's get our
> semantics and use-cases in the BIPs and documented before we deploy.
I agree. There may be some impact for future changes in Bitcoin, wrt BIP
68. For BIP 112, I think the impact could be minimal, but there may be
future interpretations of nSequence. In particular, in the long term
there may be some kind of need for some kind of "timestop" bit (to
define whether to count relative blockheight or timestopped
blockheight), which already consumes unreserved space. To account for
more than one upgrade, the next future upgrade after BIP 68 may be
implemented by taking the unused most significant bit in nSequence as
defined in BIP 68 in combination with using up a version field bit.
jl1202 had previously suggested doing this for BIP 68 itself:
e7b394187fd96bd77a1c49f7c9b7a9b2 at xbt.hk
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011358.html
As-is, the only actual tradeoff made by BIP 68 is reducing range by
half. I think BIP 68 works as-is or with burning an nVersion bit today,
as it should allow for future (necessary) upgrades.
--
Joseph Poon

2023-06-07 17:35:59

- reply

📅 Original date posted:2015-08-17
📝 Original message:Hi Chris, I don't speak for Peter, but here's my opinion on the matter
anyway.
On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote:
> Can you explain how the spv node fails against an attacker with a
> non-trivial amount of hash power where a full node doesn't? To attack an
> spv wallet that is waiting for 6 or 10 confirmations, you would not only
> need to Sybil them but also summon a massive amount of hashing power to
> create a chain of headers (while forgoing the opportunity to mine valid
> blocks with that hash power).
>
> But could someone with that much hash power not Sybil a full node and give
> them a chain for valid blocks (but on an orphan fork)? The failure model
> doesn't seem specific to spv to me.
With SPV, it is possible to create a transaction that spends from
non-existent coins. With sufficient hashpower, you can construct an SPV
proof which sends 1,000 bitcoin to the victim. The attack is
"overloadable" in the sense that the attacker is never out of money
(they never needed to have 1,000 BTC in the first place). Whereas if the
victim is running a full node, the attacker must be signing and spending
real outputs in their control, there is a possibility in a re-org that
the victim will eventually get their money if it gets re-orged back.
On a more fundamental level, the SPV attack isn't on re-orging real/live
transactions, it's an attack on *how much money you currently have*. If
the client is using SPV, they never had the money in the first place
when attacked, irrespective of re-orgs.
It is possible to attack thousands of people at once (everyone gets
1,000 bitcoin in false transactions) with a fraction of the hashpower
(lie in wait until you get a sufficiently long chain of blocks). If you
wished to attack a full-node, it requires you orphaning a chain of valid
blocks *live*, meaning you have to send real coins in a real transaction
to the victim first. With SPV validation, you only need to construct a
chain of invalid blocks off the current blockheight *whenever*. This
means you can attack with substantially less hashpower; you don't need
51% of the hashpower to attack SPV wallets. It may be economically
unviable to attack a single victim with a full node within a very short
timeframe, but it can be economically viable to attack thousands of
victims doing SPV validation in a long timeframe.
Note I'm not arguing that SPV should be compeletely avoided, I don't
have a solid opinion on that (and some threats can definitely be
mitigated in various ways, and I certainly like/appreciate the
convenience of SPV), but the current SPV security model is definitely
weaker than running a full node (if you're handling a lot of money, you
should be running a full node), are these issues not well-known by all
in the bitcoin community?
--
Joseph Poon

2023-06-07 17:34:57

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev wrote:
> If anyone feels strongly about this, please speak up.
>
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > I repeated my nit on https://github.com/bitcoin/bips/pull/179
I am also indifferent, but also dislike technical debt.
It should maybe be noted for those who wish to do/write-code-for mempool
transaction selection (irrespective of one's opinion on it) that lower
is better, since transactions with shorter relative locks are
transactions with "higher priority".
--
Joseph Poon

2023-06-07 17:34:55

- reply

📅 Original date posted:2015-08-13
📝 Original message:Very cool! This will certainly help make Lightning Network testable on
the main-chain and permit channels to remain open indefinitely. I'm
looking forward to it.
On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:
> // Note that unlike CHECKLOCKTIMEVERIFY we do not need to
> // accept 5-byte bignums since any value greater than or
> // equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
> // anyway. This limitation just happens to coincide with
> // CScriptNum's default 4-byte limit with an explicit sign
> // bit.
I haven't tested the details of this, but is there another bit available
for use in the future for the relative blockheight?
I strongly believe that Lightning needs mitigations for a systemic
supervillan attack which attemps to flood the network with transactions,
which can hypothetically be mitigated with something like a timestop
bit (as originally suggested by gmaxwell).
Summary: If a block is flagged as timestopped (whether automatically or
by vote or other mechanism), then an auxillary blockheigh is frozen and
does not increment. This auxillary blockheight is only used for
accounting in timestopped height computation (and isn't used for
anything else). So as the real blockheight increments, the auxillary
blockheight can sometimes stop and stay the same. If a transaction has a
timestop bit enabled, then the transaction's OP_CSV relative height is
dependent upon the auxillary height, not the real block height. This
allows for a large backlog of transactions which must occur before a
particular (relative) block height to enter into the blockchain.
I'm not sure if it's out of scope, but it could make sense to consider
the possibility for additional state(s) with relative height computation
today. Ideally, there'd be some kind of "version" byte which can be
recontextualized into something later, but I don't know how that could
cleanly fit into the data structure/code.
--
Joseph Poon

2023-06-07 17:34:33

- reply

📅 Original date posted:2015-08-10
📝 Original message:Hi,
On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote:
> Off-chain transactions, whether it's Lightning or something else,
> potentially extract fees, which may otherwise be paid to miners, if the
> transactions were actually on-chain.
>
> In this context, wouldn't it be contradictory, maybe even harmful, to
> aim for an environment, where some/many/most transactions are off-chain?
I think the fee market's long-term implications for mining rewards is
very important as well! However, opening and closing channels will not
be infrequent to the point that it will never happen with Lightning.
Individuals that fill up their channel will need to accommodate
accumulation (as well as those that do a lot of disbursement). These
fund flows are not too rare, and huge payments (think the equivalent to
wire transfers today) will probably be still on-chain. I think the
payment size of micropayments to credit cards are Lightning-scale, what
people use today for wire transfers (e.g. buying a house) will be
on-chain.
What Lightning does is it mitigates the advantages that doing an end-run
around bitcoin entirely via centralized systems provides to a sufficient
level, e.g. everyone transacting on Coinbase. Having everything on
centralized services will have significantly lower on-chain transactions
than Lightning and is one of the more viable alternative off-chain
payments.
Fundamentally, without off-chain transactions, there's a paradox within
a viable fee market. If you presume that fees should be relatively
competitive (i.e. not asymptotically close to zero), that implies that
higher-value transactions *will* be prioritized over low-value
transactions, as high-value transactions are willing to pay higher fees.
Wire transfers are cheap when it's a million-dollar wire.
In my view, different transaction values is the much larger risk for
on-chain transaction fee markets, with high-value transactions crowding
out low-value transactions on-chain. With lightning, it significantly
mitigates this problem by aggregating the low-value transactions
off-chain.
--
Joseph Poon

2023-06-07 17:34:22

- reply

📅 Original date posted:2015-08-11
📝 Original message:Hi Benjamin,
On Sat, Aug 08, 2015 at 02:01:58PM +0200, Benjamin via bitcoin-dev wrote:
> How do you know who is who online?
If a node is not online, then the payment can be cancelled and
re-routed.
> If Alice and Bob want to transact and haven't exchanged keys before
> they need public-key infrastructure out-of-band to identify
> themselves. Which means they are using SSL and Certificate authorities
> and trust them.
Lightning doesn't solve the key exchange problem (perhaps something like
Namecoin will help in the future). Bitcoin faces this problem today. How
do you know the bitcoin address belongs to the recipient without
trusting CAs? What if, in the case of the majority of bitcoin payments
today, the bitcoin address was not signed and the recipient claimed to
have never received their funds? There should be signed proof of payment
in every transaction for this reason.
> If you have non-cooperative hubs they could flood the network and make
> it unusable. And why should hubs cooperate? There are no incentives in
> the system.
There are some incentives towards keeping the system functional via
fees. If you attempt to flood the system, you'll likely be paying some
fees -- someone running a node will not interpret it as an attack, as
they're getting some money (probabably substantially higher as they will
increase fees to ensure network availability).
I agree that it's very important to think through varius attack models.
--
Joseph Poon

2023-06-07 17:33:13

- reply

📅 Original date posted:2015-08-10
📝 Original message:Hi Hector,
On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote:
> Is the Lightning system limited in the number of hops there can be in
> the payment channel? I am looking at the initial Lightning slides
> presented in February and it looks like the locktime decrements by
> 1-day along each hop. So the more hops there are the longer my
> bitcoins are potentially locked up for?
The hops are limited to the time-value which the sender wishes to pay
and the minimum acceptable timeout between each hop. It should be
relatively cheap if you game it out, though (I don't forsee me opening a
1 BTC channel and being able to make $5 per month...)
1-day is used as a convenience. However, the time between hops should be
somewhat long, as the intermediate steps can be extended further when
you want to offload the HTLCs to others who have a channel open with
both counterparties. E.g. Alice sends a payment to Dave through Bob and
Carol. Bob has a channel with Carol and has an HTLC with it, but that
channel seems to be used a lot. Erin has a relationship to both Bob and
Carol, she can offload the payment so that the payment actually goes to
A->B->E->C->D. B<->C is now completely clear.
> > On Aug 9, 2015 1:15 PM, "Hector Chu" <hectorchu at gmail.com> wrote:
> >> In the Lightning network it is assumed that the balances can always
> >> be settled on the blockchain if any of the parties along the
> >> channel has a problem. What if the fee on the settlement
> >> transactions is not high enough to enter the blockchain? You can't
> >> do replace-by-fee after the fact. Do the fees always have to assume
> >> worst case scenarios on the Bitcoin fee market?
How do you send coins if you wanted to send funds below the current
IsStandard value? It should be no different. If your wallet can't send
funds below the IsStandard value on-chain today, then I don't think it
should be able to to in the future, right? If you send funds *at* the
minimum IsStandard value today, you're probably paying really high fees,
this is a problem that exists today.
--
Joseph Poon

2023-06-07 17:33:10

- reply

📅 Original date posted:2015-08-10
📝 Original message:Hi Gavin,
On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make it all work.
I'm writing a (hopefully more accessible) summary on Lightning
currently. It might not go into too much detail with infrastructure, but
is a bit more UX focused.
> A customer starts with eleven on-chain bitcoin. They want to pay for a nice
> cup of tea. Walk me through what happens before/during/after the
> transaction, assuming I have a lightning-enabled wallet on my iPhone and
> the tea shop has a lightning-enabled cash register.
>
> Assume neither the customer nor the tea shop are technically sophisticated
> -- assume the customer is using an SPV wallet and the tea shop is using a
> service similar to Bitpay.
It's a bit of a tangent, but I see it as necessary that all Lightning
services/wallets support on-chain payments for a multitude of reasons,
including usability and long-term security/fungibility. For that reason,
the UX flow for payment after channels are established should not be
significantly different than Payment Protocol based payment flows (with
the only exception being a possible additional fee dialog box/alert when
the fees will be higher than expected/on-chain).
--
Joseph Poon

- reply

- reply

- reply

- reply

- reply

- reply

- reply

- reply

📅 Original date posted:2015-05-07
📝 Original message:Hi Matt,
I agree that starting discussion on how to approach this problem is
necessary and it's difficult taking positions without details on what is
being discussed.
A simple hard 20-megabyte increase will likely create perverse
incentives, perhaps a method can exist with some safe transition. I
think ultimately, the underlying tension with this discussion is about
the relative power of miners. Any transition of blocksize increase will
increase the influence of miners, and it is about understanding the
tradeoffs for each possible approach.
On Thu, May 07, 2015 at 10:02:09PM +0000, Matt Corallo wrote:
> * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
I think the long-term fee incentive structure needs to be significantly
more granular. We've all seen miners and pools take the path of least
resistance; often they just do whatever the community tells them to
blindly. While this status quo can change in the future, I think
designing sane defaults is a good path for any possible transition.
It seems especially reasonable to maintain fee pressure for normal
transactions during a hard-fork transition. It's possible to do so using
some kind of soft-cap structure. Building in a default soft-cap of 1
megabyte for some far future scheduled fork would seem like a sane thing
to do for bitcoin-core.
It seems also viable to be far more aggressive. What's your (and the
community's) opinion on some kind of coinbase voting protocol for
soft-cap enforcement? It's possible to write in messages to the coinbase
for a enforcible soft-cap that orphans out any transaction which
violates these rules. It seems safest to have the transition has the
first hardforked block be above 1MB, however, the next block default to
an enforced 1MB block. If miners agree to go above this, they must vote
in their coinbase to do so.
There's a separate discussion about this starting on:
CAE-z3OXnjayLUeHBU0hdwU5pKrJ6fpj7YPtGBMQ7hKXG3Sj6hw at mail.gmail.com
I think defaulting some kind of mechanism on reading the coinbase seems
to be a good idea, I think left alone, miners may not do so. That way,
it's possible to have your cake and eat it too, fee pressure will still
exist, while block sizes can increase (provided it's in the miners'
greater interests to do so).
The Lightning Network's security model in the long-term may rely on a
multi-tier soft-cap, but I'm not sure. If 2nd order systemic miner
incentives were not a concern, a system which has an enforced soft-cap
and permits breaching that soft-cap with some agreed upon much higher
fee would work best. LN works without this, but it seems to be more
secure if some kind of miner consensus rule is reached regarding
prioritizing behavior of 2nd-layer consensus states.
No matter how it's done, certain aspects of the security model of
something like Lightning is reliant upon having block-space
availability for transactions to enter into the blockchain in a timely
manner (since "deprecated" channel states become valid again after some
agreed upon block-time).
I think pretty much everyone agrees that the 1MB block cap will
eventually be a problem. While people may disagree with when that will
be and how it'll play out, I think we're all in agreement that
discussion about it is a good idea, especially when it comes to
resolving blocking concerns.
Starting a discussion on how a hypothetical blocksize increase will
occur and the necessary blocking/want-to-have features/tradeoffs seems
to be a great way to approach this problem. The needs for Lightning
Network may be best optimized by being able to prioritizing a large mass
of timeout transactions at once (when a well-connected node stops
communicating).
--
Joseph Poon

2023-06-07 15:32:34

- reply

📅 Original date posted:2015-04-26
📝 Original message:On Sat, Apr 25, 2015 at 11:51:37PM -0700, Joseph Poon wrote:
> signs the sigScript of the redeemed output.
Err, typo, I meant:
... signs the *scriptPubKey* of the redeemed output.
--
Joseph Poon

2023-06-07 15:32:33

- reply

📅 Original date posted:2015-04-26
📝 Original message:On Sun, Apr 26, 2015 at 03:01:10AM +0300, s7r wrote:
> It's true that malleability is not the end of the world, but it is
> annoying for contracts and micropayment channels, especially refunds
> spending the fund tx before it is even in the blockchain, relying
> solely on its txid.
Agreed, needing the transaction to be signed & broadcastable before the
refunds can be generated is similar to paying for a contract before the
terms have been decided.
> I think we can solve both by using NORMALIZEDTXID - wouldn't this be
> simpler and easier to implement?
The current problem is that SIGHASH_NORMALIZED_TXID as presently
discussed implies stripping the sigScript, which is not sufficient for
the Lightning Network.
The currently discussed SIGHASH_NORMALIZED_TXID does not permit chained
transactions 2 levels deep, which is necessary for Lightning as well.
The path from the Commitment -> HTLC -> Refund requires up to 3 levels
deep of transactions.
Suppose TxA -> TxB -> TxC -> TxD. All outputs are 2-of-2 multisig. TxA
has already entered into the blockchain, the rest have not yet been
broadcast. If TxB spends from TxA, it doesn't need new sighash flags, it
just does a plain SIGHASH_ALL. However, TxC needs
SIGHASH_NORMALIZED_TXID due to malleability risks.
SIGHASH_NORMALIZED_TXID works for TxC because the sigScript can change,
but because TxA's txid has already entered the blockchain, the parent's
input txids cannot change (with high degrees of certainty).
However, with TxD, the txid of TxB may be different, which will result
in an invalid transaction if SIGHASH_NORMALIZED_TXID only strips the
sigScript when obtaining the normalized txid of TxC. The reason for this
is TxC's input txid of TxB has changed (TxC's input 0 txid of TxB)!
Therefore, a functional SIGHASH_NORMALIZED which permits chained
transactions requires the parent transaction's sigScript *AND* txid to
be stripped when determining the parent's normalized txid. Similar to
OP_CHECKSIG, a part of the normalized TXID includes each input's
scriptPubKey, e.g. TxC's normalized TXID includes TxB's scriptPubKey
output which it is spending, so when TxD signs TxC's normalized TXID, it
includes TxB's output (this is a cheap way of increasing uniqueness but
is not an absolute necessity if it's too difficult). All this data
should be immediately available when validating the transaction and
appending it to the UTXO set.
If the txid and sigScript are removed when building the normalized input
txid as part of the spend/signature, it should be possible for chained
transactions to work. However, this isn't absolute security against
replay attacks. If there are two spends with all inputs having the same
values *AND* the same scriptPubKeys per input, then it can be replayed.
The odds of this occurring seems like a sort of uncanny valley of risks;
it's low enough that it shouldn't ever happen which may result in a lack
of documentation, so when it does happen it'll be a big surprise. So,
even if this "safer" method becomes a softfork, perhaps great care
should be taken before making this a default method of spending when the
sighash flag is not an absolute necessity (i.e. "don't do it!" I'm all
in favor of giving this a scary name so developers won't inadvertently
think "hey, normalization sounds like a good thing to do").
That said, it should cover an overwhelming majority of potential
replays, it's nearly impossible to create a "duplicate" replayable tx of
someone *else's* send, since the poteintally "replayable" transaction
signs the sigScript of the redeemed output.
As a side note, SIGHASH_NORMALIZED does not permit spending from any
transaction, which is desirable for the Lightning Network (HTLCs may
persist in new Commitment Transactions). However, this is merely a "nice
to have" and is not an absolute necessity, there is no significant loss
of functionality, merely some slight slowdown from significantly more
signatures. For Lightning in particular, the effect would probably be
batching Commitment Transactions (e.g. 1 mass update per second per
channel), with the only major discernable penalty is an order of
magnitude greater storage of signatures.
Additionally, I think it was Mark Friedenbach who brought up that
SIGHASH_NORMALIZED creates significant complexities with the need for an
additional hash with every UTXO (almost doubling the UTXO set size), and
with nodes which already have UTXO pruning enabled, it'll require
downloading the entire blockchain. I'm not sure if this problem is
insurmountable or not, but if a normalized sighash becomes the most
ideal candidate for a malleability soft-fork, then sooner may be better
than later as more nodes start using the pruning patch.
> Why are we talking about P3SH when we can just upgrade
> P2SH to support additional OP codes?
Assuming you mean the current P2SH scriptPubKey format, it's not
possible to do so while making it a soft fork. If you use OP_EQUAL,
current nodes will treat "P3SH" transactions as P2SH ones.
I'm in favor of keeping P3SH conservative. It's possible to have your
cake and eat it too, by enabling script versions within P3SH.
If you create P3SH as:
OP_DUP <20-byte hash> OP_EQUALVERIFY
The redeemScript has the first byte as a version number, and there is
also an OP_TRUE pushed right before the redeemScript. The scriptSig
would look something like:
<sigs...> OP_TRUE <3 redeemScript>
When executing the script, the last item on the stack verifies against
the hash, then the redeemScript is copied/read, the 3 is popped off
(first byte unsigned int), the OP_TRUE is popped off the stack, and the
script then executes P3SH "version 3" (again, it is the first byte, NOT
an opcode). Any non-known version will return everything as true and not
continue with execution of the script, to permit future soft-forks. The
OP_TRUE is to ensure there is a OP_TRUE left on the stack just in case
for older nodes as this is an EQUALVERIFY.
This works because the address, 20-byte hash, has the 3 version number
as part of the hash, so it is the recipient who determines the version
number. For future soft-forks, it's incredibly flexible, just make the
version byte to 4. Prior addresses work the same, and it's not possible
to accidentally send it using different scripting versions. Perhaps this
can make things upgradeable enough that a malleability sighash flag can
go in sooner rather than later.
--
Joseph Poon