Avatar
kalle
4149bd2ca7c08ab6321dc1f54176c78acd295daa2030dca04e8010ad992e714d
Author of Grokking Bitcoin and Bitcoin Development Philosophy

Ok, understood! Thanks for reply.

So after you've plugged in the first signer, you could for a k-of-t setup try each possible set of k signers and for each set that includes the plugged in signer, you show the possible cosigners. Is that what you're suggesting?

Couldn't you instead just sign all possible sets with the first plugged-in device, then plug in the next and filter out the sets of k signers further, and so on until there's only one such set left after the last device is plugged in? Is there danger in signing frivolously like this? They all sign the same message (i.e. a bitcoin input), right?

nostr:npub1j8d6h8mzvc8f2fvysrf09nlkmn7m2ylj32zl5na4tm5e8fd5dqysrg26k2 This looks amazing. But why do you have to select which two signers to sign with at 1:34 in the clip? On the next screen, the app seems to automatically identify which of the two devices you plugged in.

Never heard of Frostsnap! Amazing and beautiful idea for setup of FROST threshold signatures. https://frostsnap.com/demo.mp4 https://frostsnap.com

Yeah , given that AAA is the best rating there is to buy, they should've stayed in business longer. Can't trust these ratings. I smell corruption.

nostr:npub18d4r6wanxkyrdfjdrjqzj2ukua5cas669ew2g5w7lf4a8te7awzqey6lt3 nostr:npub1hvw02fgyxhl5whxckv4vkglraeamar7r3a54zuztg7v9zw28vukq5a5e8q On my mempool dot space account it says "You are currently on the waitlist. You will get notified once you are granted access." What does that mean? What's there to wait for? How long does that usually take?

Elvis and the kernel

Few...

Bitcoin is not the best thing that has happened to humanity in 100 years.

-regtest is.

Replying to Avatar kalle

nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm Did you deliberately take down full-rbf1.btc.petertodd.net and full-rbf4.btc.petertodd.net?

```

2023-12-02T19:40:14Z connect() to 217.199.103.141:8333 failed after wait: No route to host (113)

2023-12-02T19:41:14Z connect() to 185.254.198.243:8333 failed after wait: Connection refused (111)

```

4 was gone before my log rotation, and 1 disappeared on Nov 14.

Should I delete them from my conf? What about 2 and 3?

$ bcli getaddednodeinfo

[

{

"addednode": "full-rbf1.btc.petertodd.net",

"connected": false,

"addresses": [

]

},

{

"addednode": "full-rbf2.btc.petertodd.net",

"connected": true,

"addresses": [

{

"address": "195.189.226.74:8333",

"connected": "outbound"

}

]

},

{

"addednode": "full-rbf3.btc.petertodd.net",

"connected": true,

"addresses": [

{

"address": "91.231.182.136:8333",

"connected": "outbound"

}

]

},

{

"addednode": "full-rbf4.btc.petertodd.net",

"connected": false,

"addresses": [

]

}

]

nostr:npub1ej493cmun8y9h3082spg5uvt63jgtewneve526g7e2urca2afrxqm3ndrm Did you deliberately take down full-rbf1.btc.petertodd.net and full-rbf4.btc.petertodd.net?

```

2023-12-02T19:40:14Z connect() to 217.199.103.141:8333 failed after wait: No route to host (113)

2023-12-02T19:41:14Z connect() to 185.254.198.243:8333 failed after wait: Connection refused (111)

```

4 was gone before my log rotation, and 1 disappeared on Nov 14.

Should I delete them from my conf? What about 2 and 3?

Looks very much like the output of Core Lightning cli when used with flag -F:

```

$ lightning-cli -F listchannels |head

channels[0].source=02e4ebfc64bf742e100f7ed1f4f9c4f3ce03109face9cf5eab58529bd3a5fc6ce9

channels[0].destination=02ff30e83896d453cfc89ff4dd06d23d793b7246f154c210324adc1d42c849ce74

channels[0].short_channel_id=771657x2489x1

channels[0].direction=0

channels[0].public=true

channels[0].amount_msat=3000000000

channels[0].message_flags=1

channels[0].channel_flags=2

channels[0].active=false

channels[0].last_update=1701194704

```

Very useful

Looks much nicer to me! But now I see that the percentage isn't 100% on the last row. I guess it should?