Tyler H [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-04-07 to 2018-06-10
💬 Posted a total of 20 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:49:54

- reply

📅 Original date posted:2018-04-20
📝 Original message:
I like the efficiency your method brings and I'm also not that enthused
about bloating the blockchain with "non-financial data", however I do think
there's value in having the data live in the base chain, both from
accessibility and censorship resistance of the data to less additional
"networks". Already today any user that includes a commensurate miner's fee
can use the pushdata opcodes and add whatever data they want to the
blockchain.
One thing that the design requires is a separate method of communicating
bindings and not being censored - if it were onchain, a DNS lookup could
simply be no more than a light client requesting the relevant block.
I think anything that gets seriously far along will need to have some data
crunched and if only 100 users per day would fill up blocks then of course
constraints would necessitate other avenues.
Thanks,
Tyler
On Fri, Apr 20, 2018, 00:30 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning,
>
> CLTV < unix epoch is for absolute lock time measured sanely in blocks,
> while > unix epoch is for absolute lock time measured in that arbitrary
> human-preferred unit called "seconds". I believe you mean CSV, as that is
> for relative lock time measured in blocks (but note that it has a special
> encoding, so you might be able to get 52560 precisely).
>
> The scheme as-is puts a lot of non-financial data onchain, which will make
> our bitcoin-dev colleagues cry. We can consider something similar to
> pay-to-contract instead, which is similar to Taproot (indeed
> pay-to-contract is the basis of Taproot)
>
> To create a Numerifides command, a user does the below:
>
> 1. Generates a secret private key p = random() and the public key P = p *
> G.
> 2. Encodes the Numerifides command (it could simply be a mapping "
> google.com = 127.0.0.1") as "command".
> 3. Computes the pay-to-contract public key: C = P + h(P || command) * G.
> This has corresponding private key c = p + h(P || command) that only the
> user knows.
> 4. Generates a P2WSH to the script: <52560 blocks> OP_CHECKSEQUENCEVERIFY
> OP_DROP <C> OP_CHECKSIG
> 5. Pays to that P2WSH on the Bitcoin network.
> 6. Broadcasts command, P, and the txid+outnum of the UTXO that pays to
> the P2WSH above, to the Numerifides network (not the Bitcoin network,
> Bitcoin cannot understand it).
>
> Numerifides network nodes, on receiving a command+P+outpoint, then
> verifies it by confirming that it can get C = P + h(P || command) * G, and
> that the outpoint is unspent, and pays to a P2WSH matching the above script
> template with the <C> replaced with the computed C.
>
> When the command expires (i.e. the lock time is completed) then the user
> can reclaim its locked coins from c = p + h(P || command), meaning it only
> has to memorize p and command.
>
> UTXOs that pay to the above construction that have expired the CSV will
> have the corresponding command deleted from your Numerifides database.
>
> If two commands conflict, then we simply prefer the one with higher locked
> amount (if equal, I do not know, your choice, maybe prefer the earlier
> one). And so on. What those commands are can be specified as you wish in
> your Numerifides proposal.
>
> If you insist on bringing in proof-of-work, the proof-of-work can be
> embedded in the "command" rather than on the Bitcoin blockchain. All that
> is published on the Bitcoin blockchain will be the point <C> (33 bytes) and
> a signature using c (64 bytes) plus a relatively small script, keeping
> bitcoin-dev happy.
>
> The same scheme can be used for practically any kind of asset I believe,
> not just names.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/f6e0172b/attachment-0001.html>

2023-06-09 12:49:54

- reply

📅 Original date posted:2018-04-20
📝 Original message:
Great points. IsStandard() is something I hadn't considered yet, but I
think miners are incentivized to want Numerifides transactions as a
registration will need a solid miners fee, and "revoked" names will cause
escalating fee wars that the miners can just soak up. I think a standard
that uses mappings in a sane way (and maybe pushdata2/4 won't be allowed if
255 bytes are enough) would be allowable given the benefit it brings of
truly decentralized, human-readable trust.
I also wonder what the economic incentive might be for every node to store
and gossip the Numerifides mappings - sure they want everyone to find them,
but who cares about other people? It could be a situation like the current
Bitcoin mempool where it's saved on a best-effort basis and is
semi-transient, but that makes troubleshooting lookups problematic.
Also, I know this is only tangentially related to Lightning so if this is a
discussion best left off the mailing list, just let me know.
Thanks,
Tyler
On Fri, Apr 20, 2018 at 1:46 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> I like the efficiency your method brings and I'm also not that enthused
> about bloating the blockchain with "non-financial data", however I do think
> there's value in having the data live in the base chain, both from
> accessibility and censorship resistance of the data to less additional
> "networks".
>
>
> Gossiped data is almost impossible to censor (ask Streisand how well that
> works to censor her Malibu home). However, mere gossip is often
> unverifiable.
>
> What we do here is twofold:
>
> 1. We use the blockchain layer for verification. Commands "google.com=127.0.0.1"
> are backed by actual Bitcoin satoshi being locked, sacrificing opportunity
> costs, making them costly and verifiably costly, unlike gossip which is
> unverifiable.
> 2. We use the gossip overlay for censorship resistance. Once a command
> has been confirmed on the Bitcoin blockchain, we can share that command to
> our peers on the gossip overlay, and unless all our peers are colluding, it
> is likely that a command gets out somehow.
>
> This design also uses P2WSH, so 51% miners, at least, cannot censor
> Numerifides commands: all they see is a hash of something which could be a
> LN fundchannel or a M-of-N SegWit or etc etc. We wait for the transaction
> to confirm (which starts the CSV relative-locktime countdown anyway), after
> which the miner cannot "take back" its confirmation of your Numerifide
> command without losing costly work, and only THEN reveal the P2WSH preimage
> on the Numerifides gossip overlay network.
>
> The gossip overlay then provides censorship resistance on top of that,
> revealing the preimage of the P2WSH (AFTER it has been confirmed onchain)
> and revealing your Numerifide command. It is unlikely that anyone can stop
> the gossip overlay unless they control your entire Internet connection, in
> which case you have more serious problems and might not even be able to
> have a current view of the Bitcoin blockchain anyway.
>
> Already today any user that includes a commensurate miner's fee can use
> the pushdata opcodes and add whatever data they want to the blockchain.
>
>
> Granted. It still makes bitcoin-dev cry when this is done. And in any
> case, reducing the blockchain footprint has real benefits of reducing the
> amount that gets given to miners and increasing what can be put into
> command bids anyway.
>
>
> One thing that the design requires is a separate method of communicating
> bindings and not being censored - if it were onchain, a DNS lookup could
> simply be no more than a light client requesting the relevant block.
>
>
> Possibly. Note however that the "publish everything onchain" design
> requires cooperation of a Bitcoin miner, since it seems you are using
> scriptpubkey rather than P2WSH. In particular the IsStandard() check will
> mean your transaction will not get transmitted on the normal Bitcoin peer
> network and you will need direct connection and cooperation of a Bitcoin
> miner, to get your non-standard script in a scriptpubkey.
>
> If you intend to use P2SH or P2WSH, then you will need a gossip layer to
> reveal the script preimage anyway, so you might as well use the more
> efficient P2WSH-based construction I showed.
>
> I think anything that gets seriously far along will need to have some data
> crunched and if only 100 users per day would fill up blocks then of course
> constraints would necessitate other avenues.
>
>
> Yes. Knowing that, we might as well start efficient.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/579e6c65/attachment.html>

2023-06-09 12:49:53

- reply

📅 Original date posted:2018-04-19
📝 Original message:
I'm working on a proposal called Numerifides. Full working document here:
https://github.com/tyzbit/numerifides
Highlights:
- Committed directly to Bitcoin blockchain
- Seems to solve Zooko's triangle (Decentralized, secure and human
meaningful)
- Can use already existing SPV infrastructure for lookups (like DNS
requests).
- Doesn't have the squatting problems of Namecoin (squatting a name costs
you locked up Bitcoin funds)
- Consensus revocation of names (Someone squatting google.com but the
community knows that's a lie? It's possible to "unseat" that registration)
- If you registered a name no one cares about (oeJFwlkS) no one will care
to try to unseat your name, except to steal your funds you locked up (which
need to just be high enough so as to not be dust)
- Usable for any name->data association such as Lightning nodes, DNS,
Certificate Authorities, decentralized identities etc
Already I know some concerns are in the details of implementation like the
hash function used for the transaction puzzle, censorship resistance
(though the market effect does play itself well here) and privacy concerns
(though the committed data can be encrypted or hashed before being stored
as I do envision a "catchall" unadvertised datatype where anyone can commit
anything for any purpose such as for document existence or even committing
an encrypted key to some piece of data). I also don't like the idea of
people committing IP addresses of their websites to the blockchain for all
time, but perhaps a 2nd-layer "nameserver"-like configuration can be found
for less permanent, more ephemeral data like DNS.
I'd love any feedback the list has to offer.
On Mon, Apr 16, 2018 at 6:19 AM Corné Plooy via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
>
> Op 10-04-18 om 20:34 schreef Tyler H:
> >
> > I will continue to approach the problem of securely advertising
> > human-understandable node names, and I hope someday soon I will have a
> > solution Lightning can use that retains the open, decentralized
> > properties of the technology and the underlying blockchains.
> >
> Two of my favorite approaches:
> * Namecoin-style: Register your name first-come-first-serve on a block
> chain.
> -> Provides no protection against name squatting and attackers
> registering similarly-looking names.
> * Web of Trust: I tell you I believe this pubkey really corresponds to
> this name; someone else might tell you something else. DNS is
> essentially a special case of this, where the WoT has a centralized star
> shape. TLS is another case, where there is dozens of signing parties
> (CAs), and everyone typically gets their keys signed by only one of
> them, so anyone verifying keys has to trust all these CAs. More
> generally, a WoT can have any shape though.
> -> Provides little to no protection against trusted parties lying to you.
>
> CJP
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180419/48d4b74b/attachment.html>

2023-06-09 12:49:53

- reply

📅 Original date posted:2018-04-20
📝 Original message:
"[]" are placeholders for the appropriate data. I believed that CLTV less
than the Unix epoch would be for a relative time lock but admittedly I've
never written Bitcoin script so CSV definitely could be the appropriate
opcode to be use here for a relative time lock.
52560 was meant to be a year in block time, coinciding with the duration of
the name registration.
I'll look into your proof of mainstake as that does sound similar to what
I'm working on here.
Thanks,
Tyler
On Thu, Apr 19, 2018, 23:43 ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> Offhand, I am uncertain the first script given in "Technical Proposal"
> works as a "check proof-of-work" script.
>
> Are the "[]" comments? Or are they pushes of actual data embedded in the
> SCRIPT? It seems to be comments...?
>
> OP_CheckLockTimeVerify is absolute time, not relative time. Why
> blockheight 52560 in particular? I believe this was in 2010? Or are you
> thinking OP_CHECKSEQUENCEVERIFY which imposes a relative timelock?
>
> Locking funds for a time may be enough without pulling in proof-of-work,
> especially since the Bitcoin blockchain itself is already proof-of-work.
> See my half-baked ideas for proof-of-mainstake, where locking funds in the
> mainchain is used as voting rights for correctness of the sidechain,
> avoiding normal proof-of-stake problems since the stake that backs the
> chain is on a separate proof-of-work chain.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/3b929dfe/attachment.html>

2023-06-09 12:49:52

- reply

📅 Original date posted:2018-04-10
📝 Original message:
Christian, ZmnSCPxj et al,
Your concerns have been taken seriously, and while this might provide some
useful features with regard to opening appropriate channels (and I guess
can be implemented outside of spec, if an implementation so wishes), after
consideration and some very useful feedback from Olaoluwa Osuntokun on the
LND slack, I've decided to pull my support for implementing this specific
proposal as part of this spec.
To summarize the primary issue with this proposed BOLT:
DNS in its current form cannot be trusted as part of the Lightning spec,
plain and simple.
While I've rescinded my support, I don't discourage thoughtful
implementation of functionality like this, but I do caution any
implementation to properly inform the user as to the inherent risk in
trusting DNS, and only use DNS records as a way to increase confidence, not
make guarantees, that a node is associated to the domain it says it is.
I will continue to approach the problem of securely advertising
human-understandable node names, and I hope someday soon I will have a
solution Lightning can use that retains the open, decentralized properties
of the technology and the underlying blockchains.
I leave this proposal in Robert's hands to further defend if he wishes, and
I would discourage future proposals largely similar to this but on other
authenticated technologies (for example, advertising node information via
forum posts). Any information that doesn't come from the network itself
cannot be backed by cryptographic guarantees.
Other discussions regarding public vs private nodes and channel structures
are encouraged.
Best regards,
Tyler
On Tue, Apr 10, 2018 at 5:23 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> The external party idea is interesting, but I'm fearful that it can't be
> done in a way that retains a bare minimum of privacy.
>
>
> No, of course not. "Private" channels are privacy sieves and should not
> be used by privacy-conscious entities. Since the channel is never
> published the "public" side knows that any economic activity going through
> the "private" channel must terminate on the other side.
>
> Perhaps better terms would be "published" and "unpublished" channels. We
> should really warn people that use of unpublished channels leaks your
> economic information, whereas use of published channels give the plausible
> deniability that it could be somebody else using that channel, not you.
>
> You could try contracting out to multiple external parties, so that at
> least no single entity knows *all* your economic activity. You still leak
> all your economic activity, you are simply hoping that those external
> parties do not pool their information together to get a complete profile of
> you. Seems like a quixotic endeavor. You may be better off using your own
> public node.
>
> Multiple public nodes may be useful for load distribution. You could also
> try implementation diversity, using different secure operating system,
> hardware, and LN node software for each node, in the hope that 0days have
> lower probability of affecting them all simultaneously.
>
> You could have multiple public nodes A <-> B with a published channel
> between them that is larger than normally allowed; many of the issues with
> large channels disappear when you know that you can trust each other. and
> if you really own both A and B, then you know A can trust B and vice
> versa. The purpose is load distribution: you could source half your
> invoices with one and half your invoices with the other, and the channel
> between them allows customers to use e.g. a channel to A to pay an invoice
> made by B when all other published channels to B are depleted. But in
> terms of hackability, you should really not make A trust B and vice versa,
> though.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/2817880e/attachment-0001.html>

2023-06-09 12:49:52

- reply

📅 Original date posted:2018-04-11
📝 Original message:
ZmnSCPxj,
Yes, I understand I essentially I'd have to solve that trilemma in order to
implement something suitable for Lightning.
That is why I have pulled my support for my proposal, and I do insist that
the proposal AT MOST be a convention, but not a standard, and nodes SHOULD
NOT trust DNS.
Thanks,
Tyler
On Wed, Apr 11, 2018 at 3:28 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
>
> I will continue to approach the problem of securely advertising
> human-understandable node names, and I hope someday soon I will have a
> solution Lightning can use that retains the open, decentralized properties
> of the technology and the underlying blockchains.
>
>
> I believe this faces the issue of Zooko's Triangle? Decentralized,
> Secure, Human-meaningful: pick any two.
>
> Node pubkeys are Decentralized and Secure (good luck memorizing
> store.blockstream.com node pubkey if you are merely human).
>
> Node aliases are Decentralized and Human-meaningful (nothing prevents me
> from naming my node SLEEPYARK, though).
>
> DNS is Secure and Human-meaningful (DNS registration is centralized around
> ICANN).
>
> Maybe a DNS la
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/ca4ea811/attachment.html>

2023-06-09 12:49:51

- reply

📅 Original date posted:2018-04-09
📝 Original message:
I understand now, I hadn't fully considered the necessary channels for such
a configuration, though there is still the value of domain owners being
able to advertise preferred nodes to connect to in order to pay them
efficiently. The external party idea is interesting, but I'm fearful that
it can't be done in a way that retains a bare minimum of privacy.
Thanks,
Tyler
On Mon, Apr 9, 2018 at 8:58 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> This is not the intention. This BOLT _does not_ replace bootstrapping
> seed functionality, now or ever. A client can supplement her view of the
> network by getting the graph from well-known nodes if she wishes, but no
> more. To do otherwise _would_ centralize the network to an uncomfortable
> degree. I used "autoconnect" because that's the terminology in the mobile
> wallet, but it is misleading.
>
>
> Ah, I see. Should have been "autochannel" I suppose.
>
> > I am not sure how the risk gets managed if the public and private nodes
> are owned by the same economic entity.
>
> If the public facing node gets hacked, it cannot draw funds from the
> private node, only send them out to the attacker on the network, or close
> the channels and send the funds + wallet balance to an on-chain address.
> The "warm" funds in your example sit on the C side of the B -> C channel.
>
>
> Let us break this down.
>
> Suppose we start with this state:
>
> A 2 <-> 0 B 2 <-> 0 C
>
> Now, again, suppose the situation is that B and C are owned by the same
> economic entity, Tyler & Rompert Enterprises.
>
> Suppose A pays 1 BTC to C:
>
> A 1 <-> 1 B 1 <-> 1 C
>
> Now suppose public node B is hacked. This means B can close the channels
> and move the funds onchain to the hacker onchain address. In that case, a
> total of 2 BTC can be stolen from node B.
>
> Now suppose Tyler & Rompert Enterprises decides not to actually have a
> private node C. We start with this state:
>
> A 2 <-> 0 B
>
> Suppose A pays 1 BTC to B:
>
> A 1 <-> 1 B
>
> Now suppose public node B is hacked. This means B can close the channels
> and move the funds onchain to the hacker onchain address. In that case, a
> total of 1 BTC can be stolen from node B. Compare this to the previous
> situation, where 2 BTC can be stolen from node B, *precisely because of the
> existence of B<->C*.
>
> So it is strictly better it seems, from a risk perspective, to just use a
> public node directly, than running a public node and one or more private
> nodes. You lose less this way than also funding a channel from your public
> to your private node.
>
> Either that, or you contract to an external party who takes on the risk of
> running a public node, most likely in exchange for much higher feerates to
> your private node.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/9d723a63/attachment.html>

2023-06-09 12:49:50

- reply

📅 Original date posted:2018-04-09
📝 Original message:
> Connect is not the same as make a channel with. Connect simply lets you
access gossip information. So the hard-coded node is not privileged: it
simply relays gossip information to the wallet, equivalent to getting an
entire map of the network as visible from that node. The plan is that you
connect (but NOT make a channel with) a known fixed node with known high
uptime, then the autopilot downloads the entire network map, then connects
and creates channels to nodes from the map.
This is outside of the spec, isn't it? All implementations should use a
seed service to bootstrap themselves to the network.
> The plan is that you connect (but NOT make a channel with) a known fixed
node with known high uptime, then the autopilot downloads the entire
network map, then connects and creates channels to nodes from the map.
This is not the intention. This BOLT _does not_ replace bootstrapping seed
functionality, now or ever. A client can supplement her view of the
network by getting the graph from well-known nodes if she wishes, but no
more. To do otherwise _would_ centralize the network to an uncomfortable
degree. I used "autoconnect" because that's the terminology in the mobile
wallet, but it is misleading.
I hope the additional text I've added in the RFC makes this clear, and I
regret any confusion. Most of the functionality enabled by this proposed
BOLT would be in giving users the ability to more easily open channels to
the node they intend to, by giving node operators a way to advertise their
nodes. I do think perhaps the proposed RFC could be further improved by
adding a stipulation that autopilot functionality MUST NOT rely on domains
advertising nodes, and a user MUST choose to open a channel to a node based
on the domain.
> I am not sure how the risk gets managed if the public and private nodes
are owned by the same economic entity.
If the public facing node gets hacked, it cannot draw funds from the
private node, only send them out to the attacker on the network, or close
the channels and send the funds + wallet balance to an on-chain address.
The "warm" funds in your example sit on the C side of the B -> C channel.
Regarding "hubs", I think that while the barrier to entry into running
multiple nodes isn't zero, it's low enough that even singular moderately
technical node operators might operate with their channels in such a
configuration as this to better reduce their external risk. A user with a
laptop and Docker could run multiple nodes with channels between them, for
instance, and the containers could be insulated from each other except for
Lightning protocol traffic.
Best,
Tyler
On Mon, Apr 9, 2018 at 7:31 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Tyler,
>
> > A side effect of this BOLT would be, as an example, the mobile Eclair
> wallet could be updated to accept a domain parameter to specify an initial
> node to open a user's first channel to rather than only the option to
> "autoconnect" to their hard-coded node, and the wallet could handle
> resolving and picking a node transparently, thus increasing
> decentralization of "fringe" users such as mobile users and SPV nodes.
>
> Connect is not the same as make a channel with. Connect simply lets you
> access gossip information. So the hard-coded node is not privileged: it
> simply relays gossip information to the wallet, equivalent to getting an
> entire map of the network as visible from that node. The plan is that you
> connect (but NOT make a channel with) a known fixed node with known high
> uptime, then the autopilot downloads the entire network map, then connects
> and creates channels to nodes from the map.
>
> While certainly getting a node other than the hardcoded one might let you
> avoid censorship of nodes by free software developers of the wallet, I am
> uncertain if getting gossip from a known merchant node is *better* than
> that. Certainly you can be sure that the free software developers have at
> least some nominal checks and balances (and publicly-visible codebase) to
> prevent censorship, which might not be the case for purely commercial
> enterprises.
>
> > This also allows domain operators to have one or more public nodes, but
> many private ones with channels open to their public nodes to better manage
> their risk. For example, the private nodes could be behind a firewall.
>
> I am not sure how the risk gets managed if the public and private nodes
> are owned by the same economic entity.
>
> Suppose I am a single economic entity, and I have a public node B and a
> private node C. You are the customer A who pays me.
>
> A -> B -> C
>
> Now the channel B->C contains money I own. Any transfers between B and C
> are simply money juggling around between two accounts I own. Thus my
> earnings are never in the B->C channel, but in the (public!) A->B channel.
> So attacking B will still allow hackers to take my earnings, because B->C
> only contains savings. Indeed I probably take *more* risk here, since I
> need to fund B->C rather than, say, keep that money in a cold storage paper
> in a locked vault buried beneath concrete somewhere in the jungles of
> Africa (I would like to take the time to note that this is not where I
> actually keep my cold storage).
>
> Which is not to say this is completely worthless. Perhaps B and C are
> owned by different entities: B takes on risk, and in exchange charges a
> larger-than-usual feerate for the B->C channel transfers.
>
> Alternatively, perhaps I am a large conglomerate and I have multiple
> subsidiaries. I might create a single public access node and several
> private nodes for each of my subsidiaries, giving one larger-than-normal
> (>16777215 satoshi) channel for each subsidiary. I take actual earnings
> from my single public node, and then each of my subsidiaries implicitly
> gives a report of how much they earned (I simply look up how much of each
> private channel belongs belongs to the subsidiary private node; this is
> equivalent to what the subsidiary earned).
>
> But I do not think it is possible for a single entity to use this to
> manage its own risk. Perhaps indeed "hubs" will arise who take on the risk
> of being a public node with possibly large amounts of money in their
> channels, and create private channels to their clients, which at least are
> trustless since the client can drop the channel onchain if they lose trust
> in the hub (i.e. it is still a better situation than current "merchant
> accounts" offered by exchanges, where you cannot get your money out if the
> exchange decides you are unworthy).
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/8bda40cb/attachment-0001.html>

2023-06-09 12:49:49

- reply

📅 Original date posted:2018-04-09
📝 Original message:
Christian et al,
I've added additional wording to the PR to explicitly state BOLT 12 MUST
NOT be used for node bootstrapping. I will squash the commits should this
proposal become a standard.
A side effect of this BOLT would be, as an example, the mobile Eclair
wallet could be updated to accept a domain parameter to specify an initial
node to open a user's first channel to rather than only the option to
"autoconnect" to their hard-coded node, and the wallet could handle
resolving and picking a node transparently, thus increasing
decentralization of "fringe" users such as mobile users and SPV nodes.
Criticism and feedback is enthusiastically invited.
Thanks,
Tyler
On Sun, Apr 8, 2018 at 5:48 PM Tyler H <tyzbit at gmail.com> wrote:
> Christian,
>
> I think your points are all valid. I believe the challenge with something
> like this will be in it's general use and implementation, which is why the
> RFC doesn't make mention of intended usage past mentioning different nodes
> for "clothing" or "ebooks" a domain could advertise.
>
> --Regarding looking up nodes at the time of payments:
>
> In the future, nodes could negotiate a channel open with a push amount and
> provide the TXID or payment hash as proof of their payment of the invoice.
> This wouldn't even require the channel to be usable, and merchants could
> decide to accept 1 (or even 0) confirmations of this transaction based on
> their acceptable level of risk, considering the properties of the channel
> (capacity, local balance etc). So in that use case, this would be a rough
> process of the interaction:
>
> User tries to pay lightning invoice, and it fails. The user's wallet
> offers to pay via channel opening. The user accepts. The wallet reads the
> invoice for a "domain" field, or perhaps if the wallet happens to be a
> browser, it does a SRV lookup against the current domain serving the
> invoice. The wallet looks up the domain records, and verifies the
> destination node is present. If so, the wallet picks the correct node
> based on the records present, and opens a channel with a push amount to
> it. The destination node sees this and via as some yet undetermined
> method, associates it to that payment invoice and chooses to mark it as
> "paid" or "pending X confirmations" according to whatever criteria the node
> operator wishes to use.
>
> In a simple example, you could list all of your nodes but prefer clients
> open channels to a single one, similar to ACINQ's setup with "endurance"
> and "starblocks" on testnet. This example would simply require setting
> "endurance" to have the highest priority. This also allows domain operators
> to have one or more public nodes, but many private ones with channels open
> to their public nodes to better manage their risk. For example, the private
> nodes could be behind a firewall.
>
> The result of this is that the user experience is improved, and a side
> benefit is being able to safely associate a given payment request, and by
> extension node, with a domain. Another nontrivial benefit is there will be
> more channels opened with value on the other side, allowing for receiving
> funds back from Lightning.
>
> There are some possible open questions regarding ensuring a payment
> request hasn't been spoofed, but if you present the domain to the user,
> he/she can verify that the wallet is about to open a channel to the domain
> they expect. Other issues with this are with DNS hijacking, which to be
> frank is not an unlikely scenario. Caution would be necessary, and perhaps
> cryptographic means of associating nodes and their associated domains would
> be a requirement for something like this to exist, but the proposed BOLT
> lays the groundwork for that to happen.
>
> --Future payments going through the merchant:
>
> This is probably the biggest wrinkle. The merchant _does_ have the
> ability to know when a payment transits the channel, thus reducing
> privacy. I think the proposed BOLT should only be used to improve user
> experience, not as a replacement for the decentralized nature of
> Lightning. For example, node operators will use autopilot-like
> functionality for opening channels, BUT they will be able to augment that
> with looking up common stores and merchant's domain records and open their
> own channels to them to provide alternate routes to popular anticipated
> destinations for payments, thus making their own node more valuable and
> increasing the decentralization of the network. For example, if you know
> people are going to be paying Starbucks, you can issue a DNS request of
> your own, get their current preferred node and connect, and then any node
> you have channels with will be able to pay Starbucks through you, without
> having to open a channel of their own.
>
> --Merchant crippling payments:
>
> With the convention I described above, using channel opens as proof of
> payment, if Starbucks wants to deny a customer the ability to pay McDonalds
> (or simply doesn't have the appropriate channels to do so), the user's
> wallet will simply fall back, look up mcdonalds.com, find the appropriate
> node and pay the invoice via channel opening. This also partly addresses
> point 2, as if a merchant wants to spy on its customers, it must provide
> routes to its competitors. It can either spy or deny routes, but not
> both. In addition, the onion-like nature of payments means the merchant
> can't be sure a user paid a competitor, or a node behind them, though some
> configurations of channels and nodes can definitely reduce privacy quite a
> bit (example: a tiny etsy shop only has a couple of connections, Evil
> Starbucks being one of them with the largest channel. A user paying an
> amount above the second largest channel to this shop would have to use the
> merchant's channel, and the merchant would be sure that the payment didn't
> travel any further from there.)
>
> --Network of large hubs:
> I disagree. Again, leaning on the ability to open channels with push
> amounts that have some minor assurances (authority of DNS records) that
> you're getting the node you intend, I expect routing node operators to
> preemptively open channels to merchants they expect to receive payments,
> and they could advertise their own node to do so, along with allowing
> customers to connect directly to merchants. The minimum requirement to use
> this BOLT are the same as running a Lightning node full time, plus
> ownership of a domain.
>
> With that said, I agree regarding the value of random connections in
> strengthening the network. Nodes are well-equipped to find inefficiencies
> and correct them. The intention of the BOLT is really to improve the
> on-boarding experience, along with providing an additional means to
> advertise "official" nodes to ease clients, especially mobile ones, onto
> the network.
>
> Your pessimism is warranted and invited.
>
> Apologies for the lengthy reply,
> Tyler
>
> On Sun, Apr 8, 2018 at 4:47 PM Christian Decker <
> decker.christian at gmail.com> wrote:
>
>> Hi Tyler,
>> Hi Robert,
>>
>> first of all, welcome to the mailing list, always good to have more
>> people looking and improving the spec. I quickly read through the spec
>> and it is very well written, and it looks good.
>>
>> On a conceptual level, I do however have some issues with the
>> proposal. I don't think that the kind of selective attachment to the
>> node of a merchant is beneficial to neither the node that is opening the
>> channel, nor for the network as a whole:
>>
>> - For the node opening a channel at the time of a payment is too late,
>> it basically means that for the first payment you'd have to wait for
>> an on-chain confirmation, even if we use `push_msat` to perform the
>> initial payment. This is bad for the user experience. Channels should
>> be opened ahead of time so that, when the customer enters a shop,
>> everything is already set up. Special cases are always hard to
>> communicate ("you have to wait, but only this time, then in future
>> all will be nice and quick")
>> - It also causes all future payments to go through that merchant, which
>> can now collate your shopping activity with all of your other
>> payments, and create a profile. It's basically the hub-and-spoke
>> threat with the added problem of the hub also knowing your identity.
>> - The merchant can cripple future payments that he might suspect are
>> going to a competitor (Starbucks may attempt to block payments for
>> amounts that look like coffee payments and go to their
>> competitor). Think net neutrality for Lightning.
>> - For the network as a whole this creates a network of large hubs that
>> are only weakly interconnected, or not connected at all, unless the
>> merchants are "generous" enough to maintain connections among each
>> other.
>>
>> But it's not all bad, I really like the possibility to look up a
>> merchant's node ID through DNS, so that my wallet can check (indirect)
>> connectivity to that node and try to optimize their connectivity.
>>
>> I think we should encourage people, and implement the clients, to open
>> random connections, biased towards strenghtening the overall
>> connectivity. With the gossip protocol we already disseminate enough
>> information to allow nodes to identify bottlenecks and provide
>> additional capacity to bridge them.
>>
>> Sorry for being so pessimistic, but I think it's important we move away
>> from people attempting to open targeted channels directly to the
>> merchants. I still regret publishing the IP address of SLEEPYARK.
>>
>> Regards,
>> Christian
>>
>> Tyler H <tyzbit at gmail.com> writes:
>> > Greetings,
>> >
>> > A challenge end-users face is connecting to nodes with enough liquidity
>> to
>> > pay every merchant, and failing that, finding the merchant node in a
>> > reasonably sane way to open a channel to them for payments.
>> >
>> > As it is now, people find nodes in other people's visualizers, and pass
>> > node aliases around via word of mouth which is very prone to inaccuracy
>> and
>> > MITM attacks. A current alternative is attempting to make a payment,
>> > decoding the payment request, finding the node on your graph and
>> attempting
>> > to open a channel to the merchant. This is only possible if the
>> > destination is advertising addresses.
>> >
>> > We (Robert Olsson and I) propose an additional BOLT, tentatively
>> scheduled
>> > to be BOLT 12, to allow for operators of domain names to create SRV
>> records
>> > for their nodes. This is separate from BOLT 10's seed functionality as
>> the
>> > desired outcome is to get only the nodes associated with a particular
>> > domain. This would allow, as an example, users to say to each other
>> > "connect to a Blockstream.com node" and the user can independently look
>> up
>> > that domain, find advertised nodes and connect/open channels.
>> >
>> > This also improves security from the perspective of nodes masquerading
>> as
>> > other nodes, as anyone with a domain can authoritatively list their
>> nodes.
>> >
>> > In addition, domain operators could provide subdomains for their node
>> > addresses to distinguish between nodes intended for a specific purpose,
>> > from a human perspective.
>> >
>> > Robert Olsson (rompert) and I have created
>> > https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft
>> of
>> > what the RFC could look like.
>> >
>> > Feedback is much appreciated.
>> >
>> > Best regards,
>> > Tyler (tyzbit)
>> > _______________________________________________
>> > Lightning-dev mailing list
>> > Lightning-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/128cc9b9/attachment-0001.html>

2023-06-09 12:49:48

- reply

📅 Original date posted:2018-04-07
📝 Original message:
Greetings,
A challenge end-users face is connecting to nodes with enough liquidity to
pay every merchant, and failing that, finding the merchant node in a
reasonably sane way to open a channel to them for payments.
As it is now, people find nodes in other people's visualizers, and pass
node aliases around via word of mouth which is very prone to inaccuracy and
MITM attacks. A current alternative is attempting to make a payment,
decoding the payment request, finding the node on your graph and attempting
to open a channel to the merchant. This is only possible if the
destination is advertising addresses.
We (Robert Olsson and I) propose an additional BOLT, tentatively scheduled
to be BOLT 12, to allow for operators of domain names to create SRV records
for their nodes. This is separate from BOLT 10's seed functionality as the
desired outcome is to get only the nodes associated with a particular
domain. This would allow, as an example, users to say to each other
"connect to a Blockstream.com node" and the user can independently look up
that domain, find advertised nodes and connect/open channels.
This also improves security from the perspective of nodes masquerading as
other nodes, as anyone with a domain can authoritatively list their nodes.
In addition, domain operators could provide subdomains for their node
addresses to distinguish between nodes intended for a specific purpose,
from a human perspective.
Robert Olsson (rompert) and I have created
https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft of
what the RFC could look like.
Feedback is much appreciated.
Best regards,
Tyler (tyzbit)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180407/49c5ed2f/attachment.html>

2023-06-09 12:49:48

- reply

📅 Original date posted:2018-04-08
📝 Original message:
Christian,
I think your points are all valid. I believe the challenge with something
like this will be in it's general use and implementation, which is why the
RFC doesn't make mention of intended usage past mentioning different nodes
for "clothing" or "ebooks" a domain could advertise.
--Regarding looking up nodes at the time of payments:
In the future, nodes could negotiate a channel open with a push amount and
provide the TXID or payment hash as proof of their payment of the invoice.
This wouldn't even require the channel to be usable, and merchants could
decide to accept 1 (or even 0) confirmations of this transaction based on
their acceptable level of risk, considering the properties of the channel
(capacity, local balance etc). So in that use case, this would be a rough
process of the interaction:
User tries to pay lightning invoice, and it fails. The user's wallet
offers to pay via channel opening. The user accepts. The wallet reads the
invoice for a "domain" field, or perhaps if the wallet happens to be a
browser, it does a SRV lookup against the current domain serving the
invoice. The wallet looks up the domain records, and verifies the
destination node is present. If so, the wallet picks the correct node
based on the records present, and opens a channel with a push amount to
it. The destination node sees this and via as some yet undetermined
method, associates it to that payment invoice and chooses to mark it as
"paid" or "pending X confirmations" according to whatever criteria the node
operator wishes to use.
In a simple example, you could list all of your nodes but prefer clients
open channels to a single one, similar to ACINQ's setup with "endurance"
and "starblocks" on testnet. This example would simply require setting
"endurance" to have the highest priority. This also allows domain operators
to have one or more public nodes, but many private ones with channels open
to their public nodes to better manage their risk. For example, the private
nodes could be behind a firewall.
The result of this is that the user experience is improved, and a side
benefit is being able to safely associate a given payment request, and by
extension node, with a domain. Another nontrivial benefit is there will be
more channels opened with value on the other side, allowing for receiving
funds back from Lightning.
There are some possible open questions regarding ensuring a payment request
hasn't been spoofed, but if you present the domain to the user, he/she can
verify that the wallet is about to open a channel to the domain they
expect. Other issues with this are with DNS hijacking, which to be frank
is not an unlikely scenario. Caution would be necessary, and perhaps
cryptographic means of associating nodes and their associated domains would
be a requirement for something like this to exist, but the proposed BOLT
lays the groundwork for that to happen.
--Future payments going through the merchant:
This is probably the biggest wrinkle. The merchant _does_ have the ability
to know when a payment transits the channel, thus reducing privacy. I
think the proposed BOLT should only be used to improve user experience, not
as a replacement for the decentralized nature of Lightning. For example,
node operators will use autopilot-like functionality for opening channels,
BUT they will be able to augment that with looking up common stores and
merchant's domain records and open their own channels to them to provide
alternate routes to popular anticipated destinations for payments, thus
making their own node more valuable and increasing the decentralization of
the network. For example, if you know people are going to be paying
Starbucks, you can issue a DNS request of your own, get their current
preferred node and connect, and then any node you have channels with will
be able to pay Starbucks through you, without having to open a channel of
their own.
--Merchant crippling payments:
With the convention I described above, using channel opens as proof of
payment, if Starbucks wants to deny a customer the ability to pay McDonalds
(or simply doesn't have the appropriate channels to do so), the user's
wallet will simply fall back, look up mcdonalds.com, find the appropriate
node and pay the invoice via channel opening. This also partly addresses
point 2, as if a merchant wants to spy on its customers, it must provide
routes to its competitors. It can either spy or deny routes, but not
both. In addition, the onion-like nature of payments means the merchant
can't be sure a user paid a competitor, or a node behind them, though some
configurations of channels and nodes can definitely reduce privacy quite a
bit (example: a tiny etsy shop only has a couple of connections, Evil
Starbucks being one of them with the largest channel. A user paying an
amount above the second largest channel to this shop would have to use the
merchant's channel, and the merchant would be sure that the payment didn't
travel any further from there.)
--Network of large hubs:
I disagree. Again, leaning on the ability to open channels with push
amounts that have some minor assurances (authority of DNS records) that
you're getting the node you intend, I expect routing node operators to
preemptively open channels to merchants they expect to receive payments,
and they could advertise their own node to do so, along with allowing
customers to connect directly to merchants. The minimum requirement to use
this BOLT are the same as running a Lightning node full time, plus
ownership of a domain.
With that said, I agree regarding the value of random connections in
strengthening the network. Nodes are well-equipped to find inefficiencies
and correct them. The intention of the BOLT is really to improve the
on-boarding experience, along with providing an additional means to
advertise "official" nodes to ease clients, especially mobile ones, onto
the network.
Your pessimism is warranted and invited.
Apologies for the lengthy reply,
Tyler
On Sun, Apr 8, 2018 at 4:47 PM Christian Decker <decker.christian at gmail.com>
wrote:
> Hi Tyler,
> Hi Robert,
>
> first of all, welcome to the mailing list, always good to have more
> people looking and improving the spec. I quickly read through the spec
> and it is very well written, and it looks good.
>
> On a conceptual level, I do however have some issues with the
> proposal. I don't think that the kind of selective attachment to the
> node of a merchant is beneficial to neither the node that is opening the
> channel, nor for the network as a whole:
>
> - For the node opening a channel at the time of a payment is too late,
> it basically means that for the first payment you'd have to wait for
> an on-chain confirmation, even if we use `push_msat` to perform the
> initial payment. This is bad for the user experience. Channels should
> be opened ahead of time so that, when the customer enters a shop,
> everything is already set up. Special cases are always hard to
> communicate ("you have to wait, but only this time, then in future
> all will be nice and quick")
> - It also causes all future payments to go through that merchant, which
> can now collate your shopping activity with all of your other
> payments, and create a profile. It's basically the hub-and-spoke
> threat with the added problem of the hub also knowing your identity.
> - The merchant can cripple future payments that he might suspect are
> going to a competitor (Starbucks may attempt to block payments for
> amounts that look like coffee payments and go to their
> competitor). Think net neutrality for Lightning.
> - For the network as a whole this creates a network of large hubs that
> are only weakly interconnected, or not connected at all, unless the
> merchants are "generous" enough to maintain connections among each
> other.
>
> But it's not all bad, I really like the possibility to look up a
> merchant's node ID through DNS, so that my wallet can check (indirect)
> connectivity to that node and try to optimize their connectivity.
>
> I think we should encourage people, and implement the clients, to open
> random connections, biased towards strenghtening the overall
> connectivity. With the gossip protocol we already disseminate enough
> information to allow nodes to identify bottlenecks and provide
> additional capacity to bridge them.
>
> Sorry for being so pessimistic, but I think it's important we move away
> from people attempting to open targeted channels directly to the
> merchants. I still regret publishing the IP address of SLEEPYARK.
>
> Regards,
> Christian
>
> Tyler H <tyzbit at gmail.com> writes:
> > Greetings,
> >
> > A challenge end-users face is connecting to nodes with enough liquidity
> to
> > pay every merchant, and failing that, finding the merchant node in a
> > reasonably sane way to open a channel to them for payments.
> >
> > As it is now, people find nodes in other people's visualizers, and pass
> > node aliases around via word of mouth which is very prone to inaccuracy
> and
> > MITM attacks. A current alternative is attempting to make a payment,
> > decoding the payment request, finding the node on your graph and
> attempting
> > to open a channel to the merchant. This is only possible if the
> > destination is advertising addresses.
> >
> > We (Robert Olsson and I) propose an additional BOLT, tentatively
> scheduled
> > to be BOLT 12, to allow for operators of domain names to create SRV
> records
> > for their nodes. This is separate from BOLT 10's seed functionality as
> the
> > desired outcome is to get only the nodes associated with a particular
> > domain. This would allow, as an example, users to say to each other
> > "connect to a Blockstream.com node" and the user can independently look
> up
> > that domain, find advertised nodes and connect/open channels.
> >
> > This also improves security from the perspective of nodes masquerading as
> > other nodes, as anyone with a domain can authoritatively list their
> nodes.
> >
> > In addition, domain operators could provide subdomains for their node
> > addresses to distinguish between nodes intended for a specific purpose,
> > from a human perspective.
> >
> > Robert Olsson (rompert) and I have created
> > https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft of
> > what the RFC could look like.
> >
> > Feedback is much appreciated.
> >
> > Best regards,
> > Tyler (tyzbit)
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180408/7ec182b6/attachment-0001.html>