Tadge Dryja [ARCHIVE] on Nostr: š Original date posted:2016-08-09 š Original message: > > 4. When the watcher ...
š
Original date posted:2016-08-09
š Original message:
>
> 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
>
If you're only watching 1 channel, this is OK as you're just doing one HMAC
operation per incoming tx. This works when the number of states per
channel is high but the number of channels watched is low.
If you're watching 1M channels with 1K states each, this requires 1M HMAC
operations for every incoming tx.
By giving the whole (or a truncated part) of the txid, the observing node
can put all txids being watched for into the same tree and have seek access
time independent of the number of separate channels being watched. Whether
it's 1 channel with 1 billion states, or 100M channels with 10 states each,
you have the same cpu and I/O cost per incoming tx.
I'm not clear on the advantages of sending encrypted state information to
the observer. Most information the observer needs to construct a punishing
transaction is available in the observed commitment tx; the only per-state
information which needs to be stored is the signature (and in the case of
HTLCs, the preimage). Reconstructing messages from hashes and / or
signatures isn't possible as long as there's sufficient unknown data in the
preimage or message. This is achievable by changing the pubkeys used in
the commit tx script and pubkey hash each state, without needing additional
data in an OP_RETURN.
-Tadge
On Tue, Aug 9, 2016 at 6:29 PM, Joseph Poon <joseph at lightning.network>
wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160809/0485a6e7/attachment.html>;
š Original message:
>
> 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
>
If you're only watching 1 channel, this is OK as you're just doing one HMAC
operation per incoming tx. This works when the number of states per
channel is high but the number of channels watched is low.
If you're watching 1M channels with 1K states each, this requires 1M HMAC
operations for every incoming tx.
By giving the whole (or a truncated part) of the txid, the observing node
can put all txids being watched for into the same tree and have seek access
time independent of the number of separate channels being watched. Whether
it's 1 channel with 1 billion states, or 100M channels with 10 states each,
you have the same cpu and I/O cost per incoming tx.
I'm not clear on the advantages of sending encrypted state information to
the observer. Most information the observer needs to construct a punishing
transaction is available in the observed commitment tx; the only per-state
information which needs to be stored is the signature (and in the case of
HTLCs, the preimage). Reconstructing messages from hashes and / or
signatures isn't possible as long as there's sufficient unknown data in the
preimage or message. This is achievable by changing the pubkeys used in
the commit tx script and pubkey hash each state, without needing additional
data in an OP_RETURN.
-Tadge
On Tue, Aug 9, 2016 at 6:29 PM, Joseph Poon <joseph at lightning.network>
wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160809/0485a6e7/attachment.html>;