Tadge Dryja [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-11-19 to 2016-08-15
💬 Posted a total of 9 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:46:38

- reply

📅 Original date posted:2016-08-15
📝 Original message:
There's two approaches with encrypted vs non-encrypted: the non-encrypted
design which I kindof like, is to make all the information given to the
observer not mean anything on its own. With encrypted, you achieve the
same result, but have some decryption key stuffed somewhere in the observed
transaction to reveal meaningful data which identifies the channel, but is
encrypted.
Non-encrypted can be more efficient, because it's hard to squeeze down
compact encrypted data (though see below for an attempt!). But most things
in the channel states can be obfuscated such that even if you tell
everything to the observer, they don't learn anything. (Even in the case
where the observer is watching both sides of the channel, they shouldn't be
able to match them... well other than timing, which is admittedly a very
effective way to do it!)
I skipped over HTLCs though because they didn't fit with this model. And
they really don't -- unlike the updating pubkeys in the commit tx, HTLC's
are passed though multiple nodes, so information about them can get to the
observer pretty easily. So I think HTLCs would need to be in some kind of
encrypted blob to send to the observer.
I really like txid[0:16] as the truncated txid for the observer and
txid[16:32] as the decryption key because it's simple and quite fast. This
would allow constant-time lookups into the observer's database regarless of
how many channels it's watching, which HMAC'ing the txid doesn't have.
(You could hash txid[16:32] again for the decryption key if you want 32
bytes.)
The non-HTLC data can be sent unencrypted -- it's pretty much just a
signature and hash from the tree. If there is a new HTLC (or a few) added
in that state, the node can elect to send that to the observer as well. I
think the format can be something like:
htlc #1 expiry (4 bytes)
htlc #1 preimage (20 bytes)
htlc #2 expiry (4 bytes)
htlc #2 preimage (20 bytes)
offset to previous blob (2 bytes)
decrypt key for previous blob (16 bytes)
having pointers to previous states can save a lot of space if HTLCs are
added incrementally. The "blobs" can be kept in a separate data store
indexed by state number, so it's quick to see that, e.g, state 471 also has
an HTLC from state 465, which has HTLCs from state 442. This chained
decryption may end up revealing more HTLCs than are needed (which are quick
for the observer to detect and discard) but if the fraud has occurred then
anonymity is gone anyway and it's no big deal if the observer learns a
little more -- they already learned all the important stuff.
I *think* 2 bytes is enough; it's not that an HTLC can't last more than 65K
states, it's that an HTLC can't persist > 65K states with no other HTLCs
being added during that period. A long-lived HTLC wouldn't be referenced
directly; instead later states which still had it would point to a previous
state that also pointed to it. It's a bit more work for the observer, who
might end up with hundreds of extra preimages, but I think optimizing for
space savings at the cost of CPU time when the fraud occurs is a good
trade-off. (The fraud occurs almost never, while the state data transfers
and storage happen always)
This would also allow nodes to omit or include HTLCs to the observer as
they see fit, which seems useful for micropayments which might outstrip the
abilities of the observer.
Also, yeah, padding (handwave) and timing are what make hiding the channel
very tricky, especially for HTLCs. With non-HTLC updates, it can be hard
to know when 2 nodes are updating a channel state, but with HTLCs there are
more nodes in the mix with more points for data to leak out to the
observer. That's another reason you might want to omit sending out some
portion of HTLC recovery data.
I will try coding some of this and see, because it seems to work in my head
but that's no indication it'll work on the computer :)
-Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160815/4eb6ee12/attachment.html>

2023-06-09 12:46:36

- reply

📅 Original date posted:2016-08-11
📝 Original message:
Hi, this is very interesting idea that I hadn't thought of!
> Oh, I blamed Laolu because he told me about it; sorry for misattribution.
Heh not at all, I don't know who's coming up with what either.
> > To build the revocable pubkey, Alice takes their elkrem sender hash from
> > state n, which we'll call EHn. Alice multiples EHn * G, getting a point
> > EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
> > pubkey (BP, which is never seen raw) to EPn.
>
> "never seen raw on-chain" I assume, since Bob will send it to Alice in
> setup?
Right; Alice and Bob share these base points when they're funding the
channel but if never shows up on-chain.
> So, AFACIT this scheme gives us a slightly smaller script and makes
> previous commit transactions underivable.
>
> 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.
>
That... is a very cool idea which I had not considered. Sketching it out,
it seems like you'd need some kind of bi-directional trap door function.
RSA comes to mind where repeated exponentiation to the e can be reversed by
exponentiation to the d. But in RSA "private keys" (d) and "public keys"
(e) are the same thing (scalars) but here they're different.
My gut feeling is that with secp256k1 it's not possible though. Setting up
a homomorphic relationship such that Pubkey0 lets you compute Pubkey1 seems
like it would also allow you to compute from Scalar0 to Scalar1 -- just
perform whatever additions and multiplications you did to the point on the
scalar. Definitely something to think about though, because it'd be very
cool. (In practice it doesn't really affect storage, and reduces data on
the wire a somewhat, so not a huge difference scalability-wise, but still
would be really cool if possible)
> I think changing the timeout key is harmless, but gratuitous; changing
> the revocation key is sufficient for each commitment script unguessably
> different from the last one, no?
Yeah, I didn't alter the timeout key initially, but I put it in because it
helps keep the channel private from the observer in the case where you just
send them signatures. If the timeout key is unchanging, they'd see it when
the channel close un-cooperatively and recognize the channel they were
monitoring.
For privacy, the points you add to the timeout key and revocable key also
need to be *different* points. If you add the same point to both, an
observer who knows the base points can try subtracting the timeout and
revocable base points from the observed pubkeys. If the result for both is
the same, they'll know they've found the channel they're looking for.
Thanks for the new idea to stew over on the train!
-Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/5cf6e730/attachment.html>

2023-06-09 12:46:35

- reply

📅 Original date posted:2016-08-10
📝 Original message:
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.
The script is:
DUP
[Revocable Pubkey]
CHECKSIG
NOTIF
[Timeout Pubkey]
CHECKSIGVERIFY
[timeout period]
CHECKSEQUENCEVERIFY
ENDIF
This is a little ugly as the less likely checksig (the revocable one)
happens first. Saves space in the script though and we don't pay any more
for a checksig than any other 1 byte opcode.
As an if statement, it ends up being:
if (revocable sig) || (timeout sig && CSV > timeout)
To build the revocable pubkey, Alice takes their elkrem sender hash from
state n, which we'll call EHn. Alice multiples EHn * G, getting a point
EPn. (Elkrem point n) Alice sends EPn to Bob, who adds their commitment
pubkey (BP, which is never seen raw) to EPn. The result, (RPub n = BP +
EPn), is the revocable pubkey for state n. At state n+1, Alice sends Bob
EHn. Bob can then compute the private key for Rpub n, as it's just their
commitment private key plus EHn, modulo the order of the curve.
A similar procedure is used for the timeout key; Alice adds a point to
their own timeout key, which seems kindof pointless because they know both
scalars. It obscures the commitment script by making both pubkeys
different each state, as they're all generated from the hash tree. Bob
only needs to keep track of the most recent "elkrem points" and the hash
tree itself.
Hope this is clear and sorry if I'm describing something completely
different than what you're asking about!
-Tadge

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160810/54c17813/attachment.html>

2023-06-09 12:46:34

- reply

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

2023-06-09 12:46:33

- reply

📅 Original date posted:2016-08-08
📝 Original message:
Blinded outsourcing of channel monitoring
The big risk in LN is that an attacking node can close a channel at an old,
invalidated state beneficial to the attacker, and the Bitcoin network will
accept these transactions. The node being attacked can defend by grabbing
both outputs, which will probably make such attacks quite rare. But, nodes
have to be online to detect this attack and defend against it, or risk
losing funds.
Outsourcing this vigilance can further defend against attacks by allowing
multiple parties to mount the defense. My initial thinking was that
minimizing the amount of data stored on the observer would be best, but I
don't think there's a way to make it O(log(n)) with the way Bitcoin works
today. (Sighash_noinput, some variants of MAST, etc could make that work
and we should keep that in mind, but that may be longer term)
So if it's going to be O(n), another way to make outsourcing better is to
anonimize / blind it. Of course if the observer actually sees an invalid
close and sends out a transaction moving the attacker's time-locked funds,
they will learn about how big the channel was, the txid, etc. But 99.999%
of the time, channels won't get closed at an invalid state, so the observer
doesn't actually do anything. Most of the time channels will be closed
cooperatively, but some times they'll be closed unilaterally because one
node is offline / unresponsive. We should keep privacy in either of those
cases.
States with in-flight HTLCs are another issue... if you want to keep the
data storage down, you can just not include them, and make a policy that
the sum of all the HTLCs should be less than either non-HTLC balance in the
channel. That way the attacker still loses money if they try to attack.
They potentially might not lose all of it though. You could make it
variable size and include HTLCs as well but that increases the data rate
significantly and probably hurts anonymity in various ways.
Without HTLCs, the script I have now specifies 2 pubkeys and requires 1 of
2 signatures- either from the timeout key or the revocable key. The goal
is that the observer is monitoring a channel, but even an uncooperative
close of that channel is undetectable, even after the output is spent and
the pubkeys are revealed in the p2wsh preimage. To meet this goal the two
pubkeys have to change completely with every new state, and also the
non-timelocked pubkey Hash output also needs to change each time.
A simple way to do it would be to have the two sides of the channel make up
new timeout and revocable pubkeys for each new state, but that's a lot of
data for them, and also an extra 66 bytes per state for the observer.
Instead, we can use the elkrem tree not just to revoke states, but also to
obscure the keys in each state.
To do this, the messages actually didn't change too much, but key
derivation changes a bit. At channel setup, A and B share "base points",
which are their public keys which will be used in the commitment script.
However these public keys are never used directly so I call them "points"
on the curve rather than pubkeys themselves. (Not sure what the best
convention is for that; I figure, call it a pubkey if you end up putting it
on the blockchain and making a signature with it; call it a point if it's
used otherwise, including to build a pubkey.)
When making a new state, instead of A sending B a revokable pubkey, A
instead sends two "elkrem points" specific to the state number. These
points are both deterministically derived from the same elkrem hash. For
example, if we're building state 9, A goes down the branches of their
elkrem tree to node #9, and gets a 32 byte hash. A appends ascii "t" for
the timeout point, and ascii "r" for the revocable point. A then uses
those two hashes as private scalars and multiplies by G, creating points on
the curve, or public keys. A sends those points to B as the "elkrem
points". B then adds elkrem point R to A's base point and elkrem point T
to B's own base point. The former results in A's revokable pubkey, the
latter in B's timeout pubkey for the script.
A sends elkrem points:
elkrem point R + B base point: Revokable Pubkey
elkrem point T + A base point: Timeout Pubkey
B's elkrem point R + B's refund point: Refund Pubkey hash
with these points, B signs & sends, A stores.
B sends elkrem points:
elkrem point R + A base point: Revokable Pubkey
elkrem point T + B base point: Timeout Pubkey
A's elkrem point R + A's refund point: Refund Pubkey hash
with these points, A signs & sends, B stores.
Before the state is revoked, the sender knows the scalar to generate the
elkrem points, so there's nothing hidden about the timeout and refund
pubkeys. Those just obscure the channel. The revokation pubkey is the
only one where nobody individually knows the private key for the pubkey
until the hashes are revealed.
Once the hashes are revealed and put into the tree, either party can
regenerate all the pubkeys at any previous state quickly. That's not
actually useful for the two nodes (why would you want to generate the
script of an old state?) but it's very useful for the outsourcing node.
They won't be able to recognize state n, but state 0 ... n-1 are
recognizable and can be stored efficiently.
The reason two different points are needed is that if you add the same
elkrem point to the two base points, the observer can subtract the base
points from the public key seen in the witness script.
A base point - timeout pubkey = elkrem
B base point - revokable pubkey = elkrem
if (A base point - timeout pubkey) == (B base point - revokable pubkey)
then that point must be the elkrem point, which would indicate that those
base points were used, allowing the observer to identify the channel.
Those are (I think) the only changes needed in the LN messages / protocol
itself. The design of the observer is not quite done but I have the basic
idea. It's kindof interesting, scalability-wise, because it will be
looking for a set of txids that's potentially much larger than the whole
blockchain! Basically when a node wants to give the observer an old state
to watch, it just gives a signature, a txid, and an elkrem hash. Only the
signature and txid need to be stored. Also you can drop part of the txid
at the risk of collisions, but the cost of collisions is pretty small
(mainly a few EC operations to build the pubkeys for the script), so 16 or
even 8 byte txids could work.
If the observer sees a transaction in a block which matches a txid they're
looking for, they do some sanity checks (e.g. does this tx have a p2wsh
output?) then re-create the script, by using the elkrem tree they have,
getting the state number from the tx itself (6 bytes, encoded in nLockTime
/ nSequence), generating the elkrem points, adding them to their stored
base points, hashing the script and seeing if the script matches. If it
does, , add the fixed output address, and figure out the output amount
based on the input amount. Then add the signature, which should match up
and result in a valid transaction.
This is preliminary and I wanted to send this mail about a week ago but I
kept finding ways the observer could figure out which channel it was
observing, and then devising ways to stop that.
The nice part about this way of doing it is that you can share the channel
state data with people you don't know or trust. Maybe they won't actually
watch over the channel for you, but maybe they might. If someone wanted to
be really nice, they could try to get *every* channel and observe it. All
you need is one or two nice people like that, and invalid closes become
nigh impossible.
I'll post a bit more once it's more finalized. If people see any problems
with this method please let me know!
-Tadge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160808/70c806f2/attachment.html>

2023-06-09 12:45:13

- reply

📅 Original date posted:2015-11-24
📝 Original message:
If I understand your question, it's that the both Alice and Bob must revoke
their previous transaction states and share their revocations, but someone
has to go first.
I don't think there's a good way to make this atomic (fair exchange schemes
based on hash functions instead of signatures *sounds* sortof impossible,
but who knows). But in practice there's not really an attack, in that
every update of a channel state has an initiator.
All the payments are "push" payments; if Alice wants to allocate more to
Bob, she initiates, and if Bob wants to allocate more to Alice, he
initiates. With revocations, the user initiating the channel state change
goes first.
In the case where Alice is sending more coin to Bob:
Alice signs new state, sends half signed tx to Bob.
Bob signs new state, sends half signed tx to Alice.
Alice revokes old state by sending preimage to Bob.
Bob revokes old state by sending preimage to Alice.
Done.
If Bob fails to perform the last step, the payment can be considered to not
have gone through. But Bob doesn't have much motivation to fail there. He
can leave the channel in an indeterminate state by failing to revoke with
Alice, but that indeterminate state is worse for him than a fully
determined state where he has more money.
TLDR It's not atomic so payer goes first.
Hope this helps! If not, let me know, say a bit more about what you think
the attack would be.
-Tadge
On Mon, Nov 23, 2015 at 6:36 PM, Nicolas Dorier <nicolas.dorier at gmail.com>
wrote:
> I am still learrning about Lightning Network, slowly but surely.
> As I was reviewing bip 112 (
> https://github.com/btcdrak/bips/blob/bip112sync/bip-0112.mediawiki) I
> noticed that HLTC seems to have a potential attack.
>
> When both parties want to revoke a commitment, they need to send one to
> another the revocation preimage.
> However, if not done atomically, Alice intentionally not send her
> revocation after receiving Bob's thus preventing Bob to withdraw his funds.
>
> Am I missing something ?
>
> The only way I see of fixing as is, is to require a third party expecting
> he does not collude, but this defeat the whole purpose.
>
> Nicolas,
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151123/fc57500a/attachment.html>

2023-06-09 12:45:10

- reply

📅 Original date posted:2015-11-19
📝 Original message:
Cool, I had not seen that, I'll take a look. I'm all for anything that
allows reliable spends from unconfirmed txs. If SW can get in easier,
sounds good.
-Tadge
On Thu, Nov 19, 2015 at 11:38 AM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> Nope, Luke came up with a way to do it in a soft-fork.
>
> On 11/19/15 19:12, Tadge Dryja wrote:
>
>> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses
>> many vectors for txid malleability, but maybe there are more. And more
>> importantly, it addresses 3rd party malleability. It's not helpful in
>> the context of lightning channel creation because ECDSA sigs are
>> inherently malleable. You can always re-sign the same message with a
>> different k-value and get a different signature.
>>
>> The functionality that's needed is to be able to reliably spend from
>> unconfirmed transactions. Segregated witness can accomplish that, but
>> it quite a large hard-fork change. sighash_noinput can also accomplish
>> that: as input txids are not signed, if they change, the spending
>> transaction can be modified while leaving counterparty signatures intact.
>>
>> I'm hoping to start a new "testnet-L" similar to testnet3, with this
>> sighash type so that we can test malleability mitigation out.
>>
>> (Oh also, hi mailing list, sorry I have not posted till now! But I will
>> start posting!)
>>
>> -Tadge
>>
>> On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach <mark at friedenbach.org
>> <mailto:mark at friedenbach.org>> wrote:
>>
>> The basic idea of the soft-fork plan is very simple --- have the
>> scriptPubKey be just the 20-byte hash of the redeem script. The
>> scriptSig of the spending input is empty. The actual scriptSig, with
>> the redeem script and signatures, is contained in a separate Merkle
>> tree committed to elsewhere in the block (e.g. in the last output of
>> the coinbase, or the last output of the last transaction).
>>
>> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com
>> <mailto:gsanders87 at gmail.com>> wrote:
>>
>> The hardfork variant is quite simple, if I understood it
>> correctly. You just stick the signatures in another parallel
>> merkle tree. So if you don't want to validate signatures, just
>> don't download them, and validate everything else. TXIDs don't
>> use the signature at all. Nothing to malleate, AFAIK. Not sure
>> what the softfork plan is, but it will be a talk at Scaling
>> Bitcoin HK.
>>
>> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD
>> <glenn at tarbox.org <mailto:glenn at tarbox.org>> wrote:
>>
>>
>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com
>> <mailto:sickpig at gmail.com> <sickpig at gmail.com
>> <mailto:sickpig at gmail.com>> wrote:
>>
>> Hi Pierre
>>
>> you could start here
>>
>>
>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>
>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>> https://github.com/ElementsProject/elements
>>
>>
>> There was a brief blip on Reddit:
>>
>>
>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>
>> Its weird how little information there is on Segregated
>> Witness. I'm guessing its a simple concept and those
>> working on it (sipa / gmaxwell) haven't felt the need to
>> write it up.
>>
>> That it "apparently" can be done with a soft fork similar to
>> P2SH is good news... I guess...
>>
>>
>> --
>> Glenn H. Tarbox, PhD
>> =]|[=
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> <mailto:Lightning-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/c3686d88/attachment.html>

2023-06-09 12:45:09

- reply

📅 Original date posted:2015-11-19
📝 Original message:
With sighash_noinput, signers don't include their input's txid and index.
An even more powerful version would not even sign the pubkeyscript of the
input, which would allow some cool constructions.
In the case that there are multiple utxo outpoints which would be satisfied
by a single signature, miners can decide. It can be dangerous for this
reason if you re-use pubkeys. So don't! Especially in a multisig setting,
it seems unlikely to be a problem.
-Tadge
On Thu, Nov 19, 2015 at 11:15 AM, zaki at manian.org <zaki at manian.org> wrote:
> sighhash_noinput is the miner chooses which which utxo is consumed
> assuming there are multiple candidates variant of the idea?
>
>
>
> On Thu, Nov 19, 2015 at 11:12 AM, Tadge Dryja <tadge at lightning.network>
> wrote:
>
>> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses many
>> vectors for txid malleability, but maybe there are more. And more
>> importantly, it addresses 3rd party malleability. It's not helpful in the
>> context of lightning channel creation because ECDSA sigs are inherently
>> malleable. You can always re-sign the same message with a different
>> k-value and get a different signature.
>>
>> The functionality that's needed is to be able to reliably spend from
>> unconfirmed transactions. Segregated witness can accomplish that, but it
>> quite a large hard-fork change. sighash_noinput can also accomplish that:
>> as input txids are not signed, if they change, the spending transaction can
>> be modified while leaving counterparty signatures intact.
>>
>> I'm hoping to start a new "testnet-L" similar to testnet3, with this
>> sighash type so that we can test malleability mitigation out.
>>
>> (Oh also, hi mailing list, sorry I have not posted till now! But I will
>> start posting!)
>>
>> -Tadge
>>
>> On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach <mark at friedenbach.org>
>> wrote:
>>
>>> The basic idea of the soft-fork plan is very simple --- have the
>>> scriptPubKey be just the 20-byte hash of the redeem script. The scriptSig
>>> of the spending input is empty. The actual scriptSig, with the redeem
>>> script and signatures, is contained in a separate Merkle tree committed to
>>> elsewhere in the block (e.g. in the last output of the coinbase, or the
>>> last output of the last transaction).
>>>
>>> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> The hardfork variant is quite simple, if I understood it correctly. You
>>>> just stick the signatures in another parallel merkle tree. So if you don't
>>>> want to validate signatures, just don't download them, and validate
>>>> everything else. TXIDs don't use the signature at all. Nothing to malleate,
>>>> AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
>>>> Bitcoin HK.
>>>>
>>>> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
>>>> wrote:
>>>>
>>>>>
>>>>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Pierre
>>>>>>
>>>>>> you could start here
>>>>>>
>>>>>>
>>>>>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>>>>>
>>>>>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>>>>>> https://github.com/ElementsProject/elements
>>>>>
>>>>>
>>>>> There was a brief blip on Reddit:
>>>>>
>>>>>
>>>>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>>>>
>>>>> Its weird how little information there is on Segregated Witness. I'm
>>>>> guessing its a simple concept and those working on it (sipa / gmaxwell)
>>>>> haven't felt the need to write it up.
>>>>>
>>>>> That it "apparently" can be done with a soft fork similar to P2SH is
>>>>> good news... I guess...
>>>>>
>>>>>
>>>>> --
>>>>> Glenn H. Tarbox, PhD
>>>>> =]|[=
>>>>>
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Lightning-dev mailing list
>>>> Lightning-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/e7a516bf/attachment.html>

2023-06-09 12:45:08

- reply

📅 Original date posted:2015-11-19
📝 Original message:
I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses many
vectors for txid malleability, but maybe there are more. And more
importantly, it addresses 3rd party malleability. It's not helpful in the
context of lightning channel creation because ECDSA sigs are inherently
malleable. You can always re-sign the same message with a different
k-value and get a different signature.
The functionality that's needed is to be able to reliably spend from
unconfirmed transactions. Segregated witness can accomplish that, but it
quite a large hard-fork change. sighash_noinput can also accomplish that:
as input txids are not signed, if they change, the spending transaction can
be modified while leaving counterparty signatures intact.
I'm hoping to start a new "testnet-L" similar to testnet3, with this
sighash type so that we can test malleability mitigation out.
(Oh also, hi mailing list, sorry I have not posted till now! But I will
start posting!)
-Tadge
On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> The basic idea of the soft-fork plan is very simple --- have the
> scriptPubKey be just the 20-byte hash of the redeem script. The scriptSig
> of the spending input is empty. The actual scriptSig, with the redeem
> script and signatures, is contained in a separate Merkle tree committed to
> elsewhere in the block (e.g. in the last output of the coinbase, or the
> last output of the last transaction).
>
> On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> The hardfork variant is quite simple, if I understood it correctly. You
>> just stick the signatures in another parallel merkle tree. So if you don't
>> want to validate signatures, just don't download them, and validate
>> everything else. TXIDs don't use the signature at all. Nothing to malleate,
>> AFAIK. Not sure what the softfork plan is, but it will be a talk at Scaling
>> Bitcoin HK.
>>
>> On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD <glenn at tarbox.org>
>> wrote:
>>
>>>
>>> On Thu, Nov 19, 2015 at 4:33 AM, sickpig at gmail.com <sickpig at gmail.com>
>>> wrote:
>>>
>>>> Hi Pierre
>>>>
>>>> you could start here
>>>>
>>>>
>>>> https://github.com/ElementsProject/elementsproject.github.io#segregated-witness
>>>>
>>>> https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf
>>>> https://github.com/ElementsProject/elements
>>>
>>>
>>> There was a brief blip on Reddit:
>>>
>>>
>>> https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh
>>>
>>> Its weird how little information there is on Segregated Witness. I'm
>>> guessing its a simple concept and those working on it (sipa / gmaxwell)
>>> haven't felt the need to write it up.
>>>
>>> That it "apparently" can be done with a soft fork similar to P2SH is
>>> good news... I guess...
>>>
>>>
>>> --
>>> Glenn H. Tarbox, PhD
>>> =]|[=
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151119/fd7ed0ed/attachment.html>