[Lightning-dev] Claiming the 1BTC Strike/HRF "Stable Channel" bounty

[Chris Stewart]

Hi Lightning Devs!

Recently Strike and HRF posted 3 bitcoin bounties for features they want to
see implemented in bitcoin. The second one is "Stable Channels".

This requires pegging your bitcoin to a fixed amount of USD value inside of
your lightning channel. This can be accomplished with Discreet Log
Contracts inside your lightning channel. We've written about it here:

https://suredbits.com/how-to-claim-the-1btc-stable-channel-bounty-from-hrf-and-strike/

There are some limitations to the blog post (updating the channel state
invalidates the DLC funding txid), but this should get you started (when
APO?!)

Don't hesitate to reach out if you have questions on the financial
engineering/DLC side of things.

-Chris
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Chris Stewart]

> I don't find too compelling the potential problem of a 'bad wallet
designer', whether lazy or dogmatic, misusing noinput. I think there are
simpler ways to cut corners and there will always be plenty of good wallet
options people can choose.

In my original post, the business that I am talking about don't use "off
the shelf" wallet options. It isn't a "let's switch from wallet A to wallet
B" kind of situation. Usually this involves design from ground up with
security considerations that businesses of scale need to consider (signing
procedures and key handling being the most important!).

>Because scripts signed with no_input signatures are only really exchanged
and used for off-chain negotiations, very few should ever appear on chain.
Those that do should represent non-cooperative situations that involve
signing parties who know not to reuse or share scripts with these public
keys again. No third party has any reason to spend value to a
multisignature script they don't control, whether or not a no_input
signature exists for it.

Just because some one is your friend today, doesn't mean they aren't
necessarily your adversary tomorrow. I don't think a signature being
onchain really matters, as you have to give it to your counterparty
regardless. How do you know your counterparty won't replay that
SIGHASH_NOINPUT signature later? Offchain protocols shouldn't rely on
"good-will" for their counter parties for security.

>As I mentioned before, I don't think the lazy wallet designer advantage is
enough to justify the downsides of chaperone signatures. One additional
downside is the additional code complexity required to flag whether or not
a chaperone output is included. By comparison, the code changes for
creating a no_input digest that skips the prevout and prevscript parts of a
tx is much less intrusive and easier to maintain.

>I want to second this. The most expensive part of wallet design is
engineering time. Writing code that uses a new sighash or a custom
script with a OP_CODE is a very large barrier to use. How many wallets
support multisig or RBF? How much BTC has been stolen over the entire
history of Bitcoin because of sighash SIGHASH_NONE or SIGHASH_SINGLE
vs ECDSA nonce reuse

I actually think lazy wallet designer is a really compelling reason to fix
footguns in the bitcoin protocol. Mt Gox is allegedly a product of lazy
wallet design. Now we have non-malleable transactions in the form of segwit
(yay!) that prevent this exploit. We can wish that the Mt Gox wallet
designers were more aware of bitcoin protocol vulnerabilities, but at the
end of the day the best thing to do was offering an alternative that
circumvents the vulnerability all together.

Ethan made a great point about SIGHASH_NONE or SIGHASH_SINGLE -- which have
virtually no use AFAIK -- vs the ECDSA nonce reuse which is used in nearly
every transaction. The feature -- ECDSA in this case -- was managed to be
done wrong by wallet developers causing fund loss. Unfortunately we can't
protect against this type of bug in the protocol.

If things aren't used -- such as SIGHASH_NONE or SIGHASH_SINGLE -- it
doesn't matter if they are secure or insecure. I'm hopefully that offchain
protocols will achieve wide adoption, and I would hate to see money lost
because of this. Even though they aren't used, in my OP I do advocate for
fixing these.

> understand the desire to be conservative with protocol changes that could
be misused. However, with just taproot and taproot public key types the
anyprevout functionality is already very opt-in and not something that
might accidentally get used. Belt-and-suspender protections like chaperone
signatures and tagged outputs have their own impacts on code complexity,
on-chain transaction sizes and transaction anonymity that also must be
considered.

I'm making the assumption that the business has decided to use this
feature, and in my OP I talk about the engineering decisions that will have
to be made support this. I'm hoping the "lazy wallet designers" -- or
perhaps people that don't follow bitcoin protocol development as rabidly as
us :-) -- can see that nuance.

-Chris



On Tue, Oct 1, 2019 at 8:36 AM Richard Myers  wrote:

> Thanks Christian for pulling together this concise summary.
>
> 1.  General agreement on the usefulness of noinput / anyprevoutanyscript /
>> anyprevout.
>>
>
> I certainly support the unification and adoption of the sighash_noinput
> and anyprevoutput* proposals to enable eltoo, but also to make possible
> better off-chain protocol designs generally.
>
> Among the various advantages previously discussed, the particular use case
> benefits from eltoo I want to take advantage of is less interactive payment
> channel negotiation.
>
> In talking with people about eltoo this summer, I found most people
> generally support adding this as an option to Lightning. The only general
> concern I heard, if any,  was the vague idea that rebindable transactions
> could be somehow misused or 

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

[Chris Stewart]

I do have some concerns about SIGHASH_NOINPUT, mainly that it does
introduce another footgun into the bitcoin protocol with address reuse.
It's common practice for bitcoin businesses to re-use addresses. Many
exchanges [1] reuse addresses for cold storage with very large sums of
money that is stored in these addreses.

It is my understanding with this part of BIP118

>Using NOINPUT the input containing the signature no longer references a
specific output. Any participant can take a transaction and rewrite it by
changing the hash reference to the previous output, without invalidating
the signatures. This allows transactions to be bound to any output that
matches the value committed to in the witness and whose witnessProgram,
combined with the spending transaction's witness returns true.

if an exchange were to once produce a digital signature from that cold
storage address with a SIGHASH_NOINPUT signature, that signature can be
replayed again and again on the blockchain until their wallet is drained.
This might be able to mitigated since the signatures commit to outputs,
which may be small in value for the transaction that SIGHASH_NOINPUT was
used. This means that an exchange could move coins from the address with a
larger transaction that spends money to a new output (and presumably pays a
higher fee than the smaller transactions).

### Why does this matter?

It seems that SIGHASH_NOINPUT will be an extremely useful tool for offchain
protocols like Lightning. This gives us the building blocks for enforcing
specific offchain states to end up onchain [2].

Since this tool is useful, we can presume that it will be integrated into
the signing path of large economic entities in bitcoin -- namely exchanges.
Many exchanges have specific signing procedures for transactions that are
leaving an exchange that is custom software. Now -- presuming wide adoption
of off chain protocols -- they will need to have a _second unique signing
path that uses SIGHASH_NOINPUT_.

It is imperative that this second signing path -- which uses
SIGHASH_NOINPUT -- does NOT get mixed up with the first signing path that
controls an exchanges onchain funds. If this were to happen, fund lost
could occur if the exchange is reusing address, which seems to be common
practice.

This is stated here in BIP118:

>This also means that particular care has to be taken in order to avoid
unintentionally enabling this rebinding mechanism. NOINPUT MUST NOT be
used, unless it is explicitly needed for the application, e.g., it MUST NOT
be a default signing flag in a wallet implementation. Rebinding is only
possible when the outputs the transaction may bind to all use the same
public keys. Any public key that is used in a NOINPUT signature MUST only
be used for outputs that the input may bind to, and they MUST NOT be used
for transactions that the input may not bind to. For example an application
SHOULD generate a new key-pair for the application instance using NOINPUT
signatures and MUST NOT reuse them afterwards.

This means we need to encourage onchain hot wallet signing procedures to be
kept separate from offchain hot wallet signing procedures, which introduces
more complexity for key management (two keychains).

One (of the few) upsides of the current Lightning penalty mechanism is that
fund loss can be contained to balance of the channel. You cannot do
something in the current protocol that will effect your funds outside of
that channel. With SIGHASH_NOINPUT, that property changes.

### A side note
In general, i think we should start disallowing uses of the SIGHASH
protocols that have unexpected behavior. The classic example of this is
SIGHASH_SINGLE [3]. I get uneasy about adding more footguns to the
protocol, which with current network behavior (address re-use)
SIGHASH_NOINPUT would be a big one.


[1] - https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
[2] -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html
[3] -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016048.html

On Mon, Sep 30, 2019 at 9:24 AM Christian Decker via bitcoin-dev <
bitcoin-...@lists.linuxfoundation.org> wrote:

> With the recently renewed interest in eltoo, a proof-of-concept
> implementation
> [1], and the discussions regarding clean abstractions for off-chain
> protocols
> [2,3], I thought it might be time to revisit the `sighash_noinput` proposal
> (BIP-118 [4]), and AJ's `bip-anyprevout` proposal [5].
>
> (sorry for the long e-mail. I wanted to give enough context and describe
> the
> various tradeoffs so people don't have to stitch them together from
> memory. If
> you're impatient there are a couple of open questions at the bottom)
>
> Both proposals are ways to allow rebinding of transactions to new outputs,
> by
> adding a sighash flag that excludes the output when signing. This allows
> the
> transaction to be bound to any output, without needing a new signature, as
> long as output script and input 

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

[Chris Stewart]

> You could purchase an auth token upfront that allows you access for some
amount of time of some number of requests (seems to be the most efficient
for APIs that would be called more than once)

This does have privacy implications. It is yet to be seen how these things
develop, but this obviously allows the server to correlate what sort of
data some one is interested in. However on a practical level it may super
easy to correlate what sort of data people are querying for with normal
heuristics.

The other thing is the accounting question, where if a person does not use
all of their allocated requests within the given time frame. Perhaps you
can allow a refund invoice to be provided up front, so the server can
refund the user of the API after a set amount of time, but that comes with
it's own issues.

We are already making the assumption that someone has a Lightning node
setup, I don't see why a user wouldn't leverage that fact to not overpay
for services. There could be an argument made for latency sensitive
applications, but you probably want to go with a dedicated provider with
colocation and a more traditional payment system if that is the case.

I agree with David Harding's analysis on DoS issues. This seems like a
pretty solvable engineering problem from the server's perspective in my
opinion.

-Chris

On Fri, Jul 5, 2019 at 12:34 PM Alexander Leishman 
wrote:

> Chris,
>
> Thanks for that explanation. I could see how this makes sense for
> lightweight data payloads because it reduces the round trip count, but I
> agree with ZmnSCPxj that this could pose a DoS risk for larger data
> payloads. This DoS risk is even more magnified for ZKCPs.
>
> I would guess that APIs selling data for lightning payments might take
> different approaches:
>
> 1. You could purchase an auth token upfront that allows you access for
> some amount of time of some number of requests (seems to be the most
> efficient for APIs that would be called more than once)
> 2. You could pay per request (good for when you would want 1 big blob of
> data)
>
> So for the case where a customer is calling the API multiple times per
> day, wouldn't it make more sense to pay upfront for future requests?
>
> Best,
> Alex
>
> Best,
> Alex
>
>
>
> On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj  wrote:
>
>> Good morning Alexander,
>>
>> > > > Putting MAC inside the encryption would help ensure that we can
>> detect data replacement over insecure channel, and use of shared secret
>> ensures only intended recipient can decrypt.
>> > >
>> > > Generally you want to MAC the ciphertext + IV, otherwise you lose
>> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>>
>> It is possible I simply misunderstand the proper use of MAC, so I shall
>> research it in more depth.
>>
>>
>> > I think the benefit here is in reducing the client-server interaction
>> for REST apis while still ensuring payment to the merchant.
>> >
>> > Let's assume that we don't have this scheme, and want to provide a
>> monetized REST API. The workflow looks like this, which is similar to what
>> our behavior is now at Suredbits with websockets.
>> >
>> > 1. Client sends request to server for invoice
>> > 2. Server returns invoice
>> > 3. Client pays invoice
>> > 4. Server sends data back, or client makes request _again_ to a server
>> and then server returns data
>> >
>> > With Nadav's scheme this is simplified to
>> >
>> > 1. Client sends request to server
>> > 2. Serves returns invoice, and encrypted payload
>> > 3. Client pays invoice
>> > 4. Client decrypts data according to Nadav's scheme
>> >
>> > This saves a round trip between the server and client. It also gives
>> atomicity to the transaction, although as you stated before there is no
>> guarantees about integrity of the encrypted data. This is generally a hard
>> problem to solve in the technical sense, but I think the reputational harm
>> of the server sending bad data will be enough to prevent this, who wants to
>> do business with some one that isn't providing the advertised service? This
>> is a interaction that is could be repeated thousands of times on a daily
>> basis.
>>
>> A client can easily DoS the server by requesting and requesting (thus
>> convincing the server to encrypt and send data immediately) and never
>> paying.
>> Whereas the first would require more resources on the client side, as the
>> server does not encrypt (or never encrypts at all) until the client has
>> shown proof-of-payment.
>>
>> Regards,
>> ZmnSCPxj
>>
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

[Chris Stewart]

Hey Alex,

I think the benefit here is in reducing the client-server interaction for
REST apis while still ensuring payment to the merchant.

Let's assume that we don't have this scheme, and want to provide a
monetized REST API. The workflow looks like this, which is similar to what
our behavior is now at Suredbits with websockets
.

1. Client sends request to server for invoice
2. Server returns invoice
3. Client pays invoice
4. Server sends data back, or client makes request _again_ to a server and
then server returns data

With Nadav's scheme this is simplified to

1. Client sends request to server
2. Serves returns invoice, and encrypted payload
3. Client pays invoice
4. Client decrypts data according to Nadav's scheme

This saves a round trip between the server and client. It also gives
atomicity to the transaction, although as you stated before there is no
guarantees about integrity of the encrypted data. This is generally a hard
problem to solve in the technical sense, but I think the reputational harm
of the server sending bad data will be enough to prevent this, who wants to
do business with some one that isn't providing the advertised service? This
is a interaction that is could be repeated thousands of times on a daily
basis.

-Chris

On Thu, Jul 4, 2019 at 5:18 PM Alexander Leishman 
wrote:

> Nadav,
>
> This is an interesting proposal, but because this still requires the
> customer to trust the merchant, I am concerned that it adds complexity
> without any meaningful guarantee to the customer. Perhaps it makes sense to
> at least include some extension field here that allows the merchant to
> include a ZKP for ZKCP-compatible data transfers? However, there are a number
> of limitations  to consider
> with those.
>
> My two cents, is that the proposed standard would only be useful for the
> edge case where a customer wants to pre-download the data before paying,
> but still trusts the merchant. What's the main use you see for that? My gut
> tells me there's a higher-level abstraction here to be standardized that
> would handle more mainstream use-cases.
>
> ZmnSCPxj,
>
> > Putting MAC inside the encryption would help ensure that we can detect
> data replacement over insecure channel, and use of shared secret ensures
> only intended recipient can decrypt.
>
> Generally you want to MAC the ciphertext + IV, otherwise you lose
> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>
> -Alex
>
>
> On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev <
> lightning-dev@lists.linuxfoundation.org> wrote:
>
>> Good morning Nadav et al.,
>>
>> > > Any node on the route of the payment knows the preimage and can
>> decrypt the data. It would be nice to tune the protocol in a way that only
>> the buyer can decrypt the data. For example we could use something like
>> this:
>> >
>> > Is this not covered by sending over the pre-image encrypted data over a
>> secure channel such as HTTPS? If anyone along the route who learns the
>> pre-image does intercept the message with the encrypted data, that data
>> will already be encrypted for the intended recipient right?
>>
>> True, but the added protection allows sending the option of sending data
>> over a non-secure channel.
>> In particular, a secure channel like HTTPS would impose an
>> encryption/decryption overhead, and then you will *also* encrypt/decrypt at
>> the application layer i.e. you are encrypting twice.
>> If you have the choice of using an insecure channel, you could take that
>> and only have the encrypt/decrypt overhead only for the preimage-encrypted
>> data.
>>
>> i.e. with this, you have the option of sending over both secure and
>> insecure channels.
>> It does not hinder use of secure channel, but enables use of insecure
>> channel.
>> Putting MAC inside the encryption would help ensure that we can detect
>> data replacement over insecure channel, and use of shared secret ensures
>> only intended recipient can decrypt.
>>
>> Regards,
>> ZmnSCPxj
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Proposal: Lightning Application Standards [LAS]

[Chris Stewart]

Hi all,

We recently proposed a standard for encrypting data with the pre-image that
is being revealed over Lightning[1]. After talking with various folks in
the ecosystem the consesus seems to be it would be a good idea to create a
repository for organizing LAS (Lightning Application Standards)[2]. The
hope here is that we can start building standards so that Lightning app
developers can design their LAPPs to be compatible with other LAPPs. This
should also make it easier for wallet developers to hook into different
LAPPs with a standard.

If this idea gains momentum, I think LAS's should be kept separate from the
BOLTs. BOLTs should define low level Lightning protocol where it is
_imperative_ that Lightning implementations comply to the BOLT standards. I
think LAS's are more of "suggestions" to make it easier for everyone to
communicate and interact with each other in a standardized way. This also
encourages the idea of segregating "backbone" implementations of the
Lightning network with higher level wallet software. This makes it easier
to distinguish what useful things library developers might want to support
vs what BOLT compliant implementations need to support. Perhaps for
pragmatic reasons for now we would just reuse the current lightning-rfc
repo[3].

In my opinion, BOLT11 could be thought of as a LAS as it does not talk
about the actual Lightning protocol, but rather a canonical way to encode
information about the protocol to end users (similar to bitcoin addresses).

-Chris

[1] -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
[2] -
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002046.html
[3] - https://github.com/lightningnetwork/lightning-rfc/
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Lite client considerations for Lightning Implementations

[Chris Stewart]

Hi all,

Hope your 2019 is off to a fantastic start. I'm really excited for
Lightning in 2019.

We are currently reviving a lite client project in bitcoin-s (
https://github.com/bitcoin-s/bitcoin-s-core/pull/280). The goal is to have
a modern replacement for bitcoinj that also can be used for L2 applications
like lightning. We also are planning on supporting multiple coins, hsms
etc.

The current plan is to implement traditional SPV, and then implement
neutrino when development is picking back up on that in bitcoin core. If
that takes too long, we will consider implementing neutrino against btcd.

What I wanted to ask of the mailing list is to give us "things to consider"
when developing this lite client from a usability perspective for lightning
devs. How can we make your lives easier?

One thing that seems logical is to adhere to the bitcoin core api when
possible, this means you can use bitcoin-s as a drop in lite client
replacement for bitcoin core.

Thoughts?

-Chris
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev