Joseph Poon [ARCHIVE] on Nostr: š Original date posted:2015-07-24 š Original message: Oh, I forgot it's ...
š
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
š 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