Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-18 📝 Original message: > This makes some sense ...

📅 Original date posted:2015-10-18
📝 Original message:
> This makes some sense (though the anchor transactions don't need to be
> P2SH, it's nicer for bitcoin's UTXO if they are).

Well, currently there is no one working on a malleability fix, so we
should probably work forwards the next available goal. ;)

>> For the current form it would be enough to have
>> SecretAHash || KeyB' || KeyB || KeyA || TxID || SignatureB (L=231B)
>> with KeyB being the node pubkey (lots of key reusage...)
>> or
>> SecretAHash || KeyB' || KeyB || KeyA || TxID || nodePubKey ||
>> SignatureB (L=264B) with KeyB as a channel key that does not need to
>> be equal with the nodePubKey.
>
> Yes, I think avoiding key reuse is good. So, to be clear, the anchor TX
> output looks like:
>
> P2SH (2 KEYA KEYB 2 OP_CHECKMULTISIG)

Having to deal with malleability, the only viable solution for anchor
transactions are with escape and fast-escape?

> I think we can do slightly better with Schnorr signatures (which you can
> simply do multisig by addition, if I understand correctly) where both
> parties cooperate to form:
>
> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
>
> That's 33+33+33+33+32+64 = 228 bytes per channel.

Interesting, I kinda feel uncomfortable with Schnorr though. It feels
like some experimental method, and at least for Java, there are very
few implementations around (and I don't feel comfortable implementing
it on my own either..)

I like the idea of adding together one object for the channel to be
sent by both nodes. Even without Schnorr it saves some bytes and the
overhead of gossipping.. We can always switch the signature to Schnorr
too..

> Also, once a node is live, I'm not sure how much of the map it will need
> to keep. It might be able to prune distant parts of the map randomly,
> and get it back from the rest of the network if needed? Requires more
> thought, though.
>
>> As I'm implementing broadcast messages anyways for other purposes (see
>> other ML post), I tent to like (2) the most, it is the most expensive
>> to attack as well I think.
>
> I agree. Least on-chain spam.

Well, all nodes can always refuse to participate in the gossip network
anyway by just never requesting data and never relaying anything
either. For a lot of things, it is very similar to the whole
blockchain. Important to keep at some points, most of it is throw-away
for individual nodes already participating in the network though.. But
I don't see this a problem anywhere soon..

Cheers,
Mats