Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-24 đź“ť Original message: On 24 July 2015 at 10:49, ...
đź“… Original date posted:2015-07-24
đź“ť Original message:
On 24 July 2015 at 10:49, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > If Alice ever tries cheating, and publishes and old commitment:
> > 800 Alice + DELAY | #Alice_42 + Bob
> > 200 Bob
> > Then Bob needs to work out which of the 100 Alice_N hashes he knows or
> can
> > work out is being abused; prior to the DELAY expiring. With millions of
> > transactions that could be a bunch of hash calculations or a 100MB lookup
> > table. Might make more sense to have a dummy output of "0: OP_RETURN 42"
> to
> > make that calculation trivial though? That could trivially be verified as
> > part of the "forms hash chain as expect" and "txn structure" checks.
> It might be millions.
If a channel is updated ~100 of times a second, and lasts for a month, that
would be 259M updates​, which on your laptop would be 22 minutes of search
time. If we're talking 3 days worth of OP_CSV delay, even that would be
pretty fine. So yeah, okay, seems plausible.
> HTLCs are harder if you assume pay2scripthash is used though. If Alice
> > published:
> >
> > 100 Alice + Delay | #Alice_55 + Bob
> > 100 Bob
> > 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
> > 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
> > 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
> > 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
> >
> > well after R1..R4 were known and Alice_55 was revealed in order to try
> > stealing most of the channel's funds, I think Bob could only claim the
> > final outputs if he could unhash the scripts, which would require having
> > remembered R1..R4 even after those contracts had long been resolved. I
> > guess it could be feasible in that case to have the extra output be "0:
> > OP_RETURN 42 #R1 #R2 #R3 #R4"?
>
> Good point! With p2sh you need to know the R hash values and timeouts
> to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
> bytes, you can't fit more than 2.
>
​You could have multiple OP_RETURN outputs though? Your txn would look like:
version
n inputs: 2
input 1: [txn] [idx] [len] [SIGA SIGB] [seq]
input 2: [txn] [idx] [len] [SIGB SIGA] [seq]
n outputs: 2 + x
​ output 1: [value] [len] [p2sh] # Alice
output 2: [value] [len] [p2sh] # Bob
output 3: [value] [len] [p2sh] # R1
output 4: [value] [len] [p2sh] # R2
output 5: [value] [len] [OP_RETURN R1R2]
...
p2sh outputs are 32 bytes total I think; OP_RETURN is 51 bytes, so you're
increasing the txn size by about 80%.
Otherwise I think you have to remember all the R's you see. But if that's
okay -- 100/second for a month is just 5GB if you just store them in the
order you see them; you can probably do something like:
- at the time of this transaction, I've seen 0 < N < 2^32 R's on this
channel
- here's a 288 bit bloom filter telling you which of the first N R's that
I've seen are worth checking
- add a single 0btc "OP_RETURN [N | bloomfilter]" output
- (or if there are 10 or less R outputs, just concatenate their indexes as
the OP_RETURN data)
Actually, I forgot about the TIMEOUT values which you'd presumably also
need; so I guess that's an extra 4 bytes to include in the database of
every R (+25%), and if you're not storing, I guess an extra OP_RETURN
output that covers 10 R's for an additional overhead of 16%, so ~96%
overhead all up.
If you consider your counterparty very reliable, then having 100% overhead
in the commitment txns might not be a big deal -- you'll almost always
close the channel cooperatively anyway, so the commitments don't get used
and the fees for the overhead won't get paid; OTOH, if your counterparty
isn't known to you, and you think it's likely they might randomly disappear
off the net and you'll have to use the commitment, then trading off disk
for fees might be sensible. You could change the choice while the channel's
operating -- if a new R value is verbatim in the output, no need to store
it locally, whether or not you've stored previous R values locally.
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150724/268e220f/attachment.html>;
đź“ť Original message:
On 24 July 2015 at 10:49, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > If Alice ever tries cheating, and publishes and old commitment:
> > 800 Alice + DELAY | #Alice_42 + Bob
> > 200 Bob
> > Then Bob needs to work out which of the 100 Alice_N hashes he knows or
> can
> > work out is being abused; prior to the DELAY expiring. With millions of
> > transactions that could be a bunch of hash calculations or a 100MB lookup
> > table. Might make more sense to have a dummy output of "0: OP_RETURN 42"
> to
> > make that calculation trivial though? That could trivially be verified as
> > part of the "forms hash chain as expect" and "txn structure" checks.
> It might be millions.
If a channel is updated ~100 of times a second, and lasts for a month, that
would be 259M updates​, which on your laptop would be 22 minutes of search
time. If we're talking 3 days worth of OP_CSV delay, even that would be
pretty fine. So yeah, okay, seems plausible.
> HTLCs are harder if you assume pay2scripthash is used though. If Alice
> > published:
> >
> > 100 Alice + Delay | #Alice_55 + Bob
> > 100 Bob
> > 200 R1 + Alice + DELAY | Bob + TIMEOUT1 | #Alice_55 + Bob
> > 200 R2 + Alice + DELAY | Bob + TIMEOUT2 | #Alice_55 + Bob
> > 200 R3 + Alice + DELAY | Bob + TIMEOUT3 | #Alice_55 + Bob
> > 200 R4 + Alice + DELAY | Bob + TIMEOUT4 | #Alice_55 + Bob
> >
> > well after R1..R4 were known and Alice_55 was revealed in order to try
> > stealing most of the channel's funds, I think Bob could only claim the
> > final outputs if he could unhash the scripts, which would require having
> > remembered R1..R4 even after those contracts had long been resolved. I
> > guess it could be feasible in that case to have the extra output be "0:
> > OP_RETURN 42 #R1 #R2 #R3 #R4"?
>
> Good point! With p2sh you need to know the R hash values and timeouts
> to spend the output (40 bytes). Since OP_RETURN is length-limited to 80
> bytes, you can't fit more than 2.
>
​You could have multiple OP_RETURN outputs though? Your txn would look like:
version
n inputs: 2
input 1: [txn] [idx] [len] [SIGA SIGB] [seq]
input 2: [txn] [idx] [len] [SIGB SIGA] [seq]
n outputs: 2 + x
​ output 1: [value] [len] [p2sh] # Alice
output 2: [value] [len] [p2sh] # Bob
output 3: [value] [len] [p2sh] # R1
output 4: [value] [len] [p2sh] # R2
output 5: [value] [len] [OP_RETURN R1R2]
...
p2sh outputs are 32 bytes total I think; OP_RETURN is 51 bytes, so you're
increasing the txn size by about 80%.
Otherwise I think you have to remember all the R's you see. But if that's
okay -- 100/second for a month is just 5GB if you just store them in the
order you see them; you can probably do something like:
- at the time of this transaction, I've seen 0 < N < 2^32 R's on this
channel
- here's a 288 bit bloom filter telling you which of the first N R's that
I've seen are worth checking
- add a single 0btc "OP_RETURN [N | bloomfilter]" output
- (or if there are 10 or less R outputs, just concatenate their indexes as
the OP_RETURN data)
Actually, I forgot about the TIMEOUT values which you'd presumably also
need; so I guess that's an extra 4 bytes to include in the database of
every R (+25%), and if you're not storing, I guess an extra OP_RETURN
output that covers 10 R's for an additional overhead of 16%, so ~96%
overhead all up.
If you consider your counterparty very reliable, then having 100% overhead
in the commitment txns might not be a big deal -- you'll almost always
close the channel cooperatively anyway, so the commitments don't get used
and the fees for the overhead won't get paid; OTOH, if your counterparty
isn't known to you, and you think it's likely they might randomly disappear
off the net and you'll have to use the commitment, then trading off disk
for fees might be sensible. You could change the choice while the channel's
operating -- if a new R value is verbatim in the output, no need to store
it locally, whether or not you've stored previous R values locally.
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150724/268e220f/attachment.html>;