Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-16 📝 Original message: On Sat, Oct 17, 2015 at ...
📅 Original date posted:2015-10-16
📝 Original message:
On Sat, Oct 17, 2015 at 07:20:30AM +1030, Rusty Russell wrote:
> KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE
AFAICS, to have a lightning channel between NODE-A and NODE-B, you just
have to have a way for those two people to be comfortable writing IOUs
to each other. HTLCs and commitments spending anchor transactions on
the blockchain is one way to do this, but you could also do it on a
pegged sidechain, or, if the two parties trusted each other, you could
do it with literal IOUs written on bits of paper. I'm not sure we want
to block people from doing those things?
Also, if you're only doing dual-signature, not quad-signature, I think
it's open to creating fake edges in the routing graph: ie, I make up to
keys AJ1 and AJ2, and publish a multisig transaction in the blockchain,
then claim there's a route between RUSTY and MATS by publishing
AJ1 AJ2 RUSTY MATS TX <SIG:AJ1 AJ2>
Then when Alice wants to route to Bob, she decides to use that edge, and
her transaction fails because it doesn't exist.
(If you just sign with RUSTY and MATS, obviously you can claim to have
a route just by referencing any multisig transaction that you know the
pubkeys of)
> > For 100k nodes and 10 open channels per node,
> > this adds up to 220MB. [...]
> 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.
Well, we could not worry about it until there are >10k nodes; and then
we'd have actual data as well?
Cheers,
aj
Published at
2023-06-09 12:44:47Event JSON
{
"id": "f7123bf389c1c12813c587a13457d0972eeffe3b431318db51475f118c3b2b94",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314687,
"kind": 1,
"tags": [
[
"e",
"a852f7164f575698e067e8fc679f5003dd9087247fc7ef7f6067ab966288eef1",
"",
"root"
],
[
"e",
"25d2b9c4972bb4a16ce3a272fde5c35d9ca183ae47b260c0ba60ddb9aabeb2a3",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-10-16\n📝 Original message:\nOn Sat, Oct 17, 2015 at 07:20:30AM +1030, Rusty Russell wrote:\n\u003e KEYA KEYB NODE-PUBKEYA NODE-PUBKEYB TXID DUAL-SIGNATURE\n\nAFAICS, to have a lightning channel between NODE-A and NODE-B, you just\nhave to have a way for those two people to be comfortable writing IOUs\nto each other. HTLCs and commitments spending anchor transactions on\nthe blockchain is one way to do this, but you could also do it on a\npegged sidechain, or, if the two parties trusted each other, you could\ndo it with literal IOUs written on bits of paper. I'm not sure we want\nto block people from doing those things?\n\nAlso, if you're only doing dual-signature, not quad-signature, I think\nit's open to creating fake edges in the routing graph: ie, I make up to\nkeys AJ1 and AJ2, and publish a multisig transaction in the blockchain,\nthen claim there's a route between RUSTY and MATS by publishing\n\n AJ1 AJ2 RUSTY MATS TX \u003cSIG:AJ1 AJ2\u003e\n\nThen when Alice wants to route to Bob, she decides to use that edge, and\nher transaction fails because it doesn't exist.\n\n(If you just sign with RUSTY and MATS, obviously you can claim to have\na route just by referencing any multisig transaction that you know the\npubkeys of)\n\n\u003e \u003e For 100k nodes and 10 open channels per node,\n\u003e \u003e this adds up to 220MB. [...]\n\u003e Also, once a node is live, I'm not sure how much of the map it will need\n\u003e to keep. It might be able to prune distant parts of the map randomly,\n\u003e and get it back from the rest of the network if needed? Requires more\n\u003e thought, though.\n\nWell, we could not worry about it until there are \u003e10k nodes; and then\nwe'd have actual data as well?\n\nCheers,\naj",
"sig": "1f7ade866daeff0dc62e8db2ab342c269e6cc294323b96ea05ce108357483062c70256d50eb1495237e915239b656a0621ced347e1584ad451f82cc67b086350"
}