<unnamed>

Public Key

npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8

Profile Code

nprofile1qqsvedxvslz9td60awhwty5ul5rjvssm9m4xftftzezqk68gcapnyygpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsxjgpr8

Publishing to

relay.primal.net

relay.damus.io

nos.lol

Last Notes

2023-06-09 12:46:34 UTC

- 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 UTC

- 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:44:01 UTC

- 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 UTC

- 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:58 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:46 UTC

- 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 UTC

- 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:38 UTC

- 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-07 17:59:16 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:52:56 UTC

- 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:16 UTC

- 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:34:57 UTC

- 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 UTC

- 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 UTC

- 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 15:46:48 UTC

- reply

2023-06-07 15:45:21 UTC

- 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

2023-06-07 15:33:39 UTC

- 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