Got plenty for a few channels but need to nail down Blake2b replay protection. Seems straight forward enough…Send from Sparrow2B to Shrike with unified sighash selected. I just need to do it
That will work, but you can also send from Sparrow BLAKE2b to another address in Sparrow BLAKE2b with unified sighash selected, or Shrike to another address in Shrike with unified sighash selected. You don’t necessarily need both Sparrow BLAKE2b and Shrike.
2 Likes
Well then. That is easier than I my mind would let me think
1 Like
Someone just opened a 400,000-sat inbound channel to my node — and I’d like to return it at parity, exactly per your bootstrap plan. One snag: the funding node (03f1024354e0ae38648a1a03e2de2fb6c236d5600ed97031c6e6fae7cab1da4f75, reachable at 2.25.130.73:9737) isn’t one of your three published nodes. If it’s yours on a new test box, say the word and I’ll open the equal channel back. If it belongs to another tester here — post up, and I’ll happily pair with you too.
My node, for anyone wanting to connect:
033f46e249373fd2111b51c158cc3e896b94321a3a8fc0a7459b407af9a04a4eae@4dpgvyg574hlju3obk4z3dt4b5dxjxawn3466psz2acip3jieoe2vrad.onion:9737
Alias: Floppy Meeting Start9, running Lightning Fork 0.21.3-beta-blake2b.17 on Start9, pointed at my Knots BLAKE2b node. The sats that will fund my side are replay-protected first — I’m not touching the base-layer wallet without the unified sighash, I’ve seen your warning about coins trapped on the wrong chain and I have no interest in learning that lesson the hard way.
My 400k sits on their side of the channel today, so the link is receive-only until that matching channel goes out.
The links don’t need to be with my node. The network has grown considerably, so as long as you get plugged in somewhere, the exact connections aren’t as important. Of course, two or more channels are better than one (so that payments can route through your node). I’ll open a channel with your node as well, so you have that second channel.
1 Like
That was me. Scroll up and you can match the node id to that in my previouse comment. I was just finding a use for a remainder of funding sats that had on my node so i opened a channel with you since i saw you on this thread anyway. But i can close the channel if you prefer. Ill go back and verify if the sats were replay protected. If they were not protected, ill close the channel. Sorry, im new to this.
I’m new to this as well. I’m fine with it and planning to reply with an equal amount. Maybe Paul or someone who knows more can speak to the replay issue. I’ll wait to reciprocate until that replay issue resolves with your 400000. I’ll monitor this chat.
1 Like
I think funding the wallet is potentially subject to replay. Currently I don’t have a way to get them back out if you sent SHA256 sats to the on-chain wallet. In the latest release from today I added in mandatory unified sighash for channel open transactions, so those at least are replay protected moving forward.
Let me look into adding a feature for recovering SHA256 sats if they are accidentally sent to the on-chain wallet.
1 Like
This is my robot’s insight: My independent check — the wait can end. I pulled LNnym’s channel-creation transaction off the Blake chain and read its raw signature: it was signed with the Blake-only signature (0x21). That means the transaction that locked LNnym’s 400,000 sats into the shared vault physically cannot exist on the main chain — so the coins inside the vault live only on Blake, exactly where you want them. Paul’s worry applies to coins still sitting loose in LNnym’s node wallet (only LNnym can check those), not to the 400k you’d be paired against. Your own return funds are the separately-proven replay-safe pile I verified earlier. Your stated condition — “wait until the replay issue resolves” — is met.