Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

Good morning list, and Nadav, > I would also like to point out the below assumption, which underlies Bass > Amplifier ("multipath payments", "base AMP") and its claim to atomicity: > > - If we agree that my secret `s` is worth `m` millisatoshi, then I (as a > perfectly rational economic

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

Hi list and ZmnSCPxj, Glad this has been helpful and I'm not just stating obvious things :) always hard to tell once the idea has been had. > I think, it is possible to make, a miniscript-like language for such things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s

Re: [Lightning-dev] OP_CAT was Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

Good point -- in our discussion, we called it OP_FFS -- Fold Functional Stream, and it could be initialized with a different integer to select for different functions. Therefore the stream processing opcodes would be generic, but extensible. -- @JeremyRubin

Re: [Lightning-dev] OP_CAT was Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

Awhile back, Ethan and I discussed having, rather than OP_CAT, an OP_SHA256STREAM that uses the streaming properties of a SHA256 hash function to allow concatenation of an unlimited amount of data, provided the only use is to hash it. You can then use it perhaps as follows: // start a new hash

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

Anthony Towns via bitcoin-dev wrote: [SNIP] > > My thinking at the moment (subject to change!) is: > > * anyprevout signatures make the address you're signing for less safe, >which may cause you to lose funds when additional coins are sent to >the same address; this can be avoided if

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

Hi Nadav, I've thought about similar problems before. Essentially you are trying to create an "access structure" on discrete logarithm (the completion of the adaptor signature in "pay-to-point"). I think the term for arbitrary combinations of AND and ORs and even N-of-M is called a *monotone

Re: [Lightning-dev] [bitcoin-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

Interesting point. The script is under your control, so you should be able to ensure that you are always using a correctly constructed midstate, e.g., something like: scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2> OP_SHA256STREAM OP_EQUALVERIFY would hash all the elements on the

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

Hi ZmnSCPxj, > I think, it is possible to make, a miniscript-like language for such things. > Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the requirement to reveal scalars rather than prove your knowledge of them. I've thought about this too.

[Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

Hi all, I've been looking at the current lightning network fees, and it shows that 2/3 are sitting on the default (1000 msat + 1 ppm). This has two problems: 1. Low fees are now a negative signal: defaults actually indicate lower reliability, and routing gets tarpitted trying them

Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

Good morning, Looks fine to me. Regards, ZmnSCPxj > Hi all, > > I've been looking at the current lightning network fees, and it > shows that 2/3 are sitting on the default (1000 msat + 1 ppm). > > This has two problems: > > 1. Low fees are now a negative signal: defaults actually indicate >