Nostr notes by William Casarin [ARCHIVE]

📅 Original date posted:2022-01-24 📝 Original message: On ...

2023-06-09T13:05:04Z

In reply to nevent1q…wnzu
_________________________

📅 Original date posted:2022-01-24
📝 Original message:
On Mon, Jan 24, 2022 at 01:54:49PM +1030, Rusty Russell wrote:
>Christian Decker <decker.christian at gmail.com> writes:
>>William Casarin <jb55 at jb55.com> writes:
>>> I think the end goal of an RPC bolt [blip] would be super powerful,
>>> so that lnsocket could talk to any lightning node, but that could be
>>> further down the line. Choosing the right data format seemed like an
>>> important step in that direction. Would love to hear your thoughts
>>> on this!
>>
>> I agree. Exchanging the transport layer underneath grpc doesn't change
>> semantics, but does unlock a number of potential use-cases. I think
>> either the JSON-RPC or grpc can serve as a basis for a common RPC
>> definition that can have any number of bindings, since we generate
>> conversion code to/from JSON-RPC and grpc we can transparently map them
>> back and forth.
>
>Yeah, I don't think we'll end up with a control standard. But I've been
>pleasantly surprised before: certainly a common subset would be nice!

I ended up just using json+commando for my prototype[1]. I'm not going
to overengineer anything yet. If there's a way write plugins for the
other implementations I could start hacking away at a common control
subset, since I do eventually want an iOS app that controls all node
implementations. I will try to get something working across multiple
implementations before writing up a spec.

Cheers,
Will

[1] http://git.jb55.com/lnsocket/file/rpc.c.html

📅 Original date posted:2022-01-18 📝 Original message: Hey ...

2023-06-09T13:05:03Z

In reply to nevent1q…q705
_________________________

📅 Original date posted:2022-01-18
📝 Original message:
Hey Christian,

I noticed you are doing RPC stuff... I'm looking to do RPC over
lightning itself. I started a C library called lnsocket[1], scrounged
from clightning parts, so that I can send messages from iOS to control
my lightning node.

I've got to the point with lnsocket where I can send TLVs to my node,
and now I'm starting to think about what format the RPC commands should
be.

I noticed the commando c-lightning plugin just uses the JSON-RPC
payload, but perhaps something more compact and rpc-friendly like grpc
would be better... which is why this cln-grpc PR peaked my curiosity.

I think the end goal of an RPC bolt would be super powerful, so that
lnsocket could talk to any lightning node, but that could be further
down the line. Choosing the right data format seemed like an important
step in that direction. Would love to hear your thoughts on this!

I've cc'd clightning/lightning-dev as well to see if anyone else is
working on this or thinking about this stuff right now.

Cheers,
Will

[1] http://git.jb55.com/lnsocket

On Tue, Jan 18, 2022 at 06:01:46AM -0800, Christian Decker wrote:
>This is the final PR in the cln-* series. It uses all the primitives we
>built in the previous 3 PRs and uses them to expose the JSON-RPC over
>grpc, with mTLS authentication builtin. You can view, comment on, or
>merge this pull request online at:
>
> https://github.com/ElementsProject/lightning/pull/5013
>
>-- Commit Summary --
>
> * cln-grpc-plugin: Add scaffolding for the cln-grpc-plugin
> * make: Add a hook for us to depend on generated files for tests
> * make: Generate grpc bindings if we want to test with rust enabled

📅 Original date posted:2021-12-15 📝 Original message: On ...

2023-06-09T13:04:50Z

In reply to nevent1q…39lu
_________________________

📅 Original date posted:2021-12-15
📝 Original message:
On Wed, Dec 15, 2021 at 01:59:49PM -0800, William Casarin wrote:
>Hey Ronan,
>
>On Wed, Dec 15, 2021 at 05:33:51PM +0000, Ronan McGovern wrote:
>>If not, what would be required to develop this?
>>* A protocol change?
>>* Could it be built with the current protocol (I see an app on LN Bits to
>>split but it doesn't seem to work).
>
>This is typically done at the application level. The fountain podcasting
>app works this way and it seems to work okish.

The tricky part is what to do when the payment partially fails. Perhaps
you keep trying with exponential backoff until the payment completes for
all parties. If this was handled at the protocol level, would you fail
the entire transaction if one of the channels failed? This is the kind
of business logic that would be tricky when designing a protocol-level
solution to this.

I think it's reasonable to handle this at the application level for now,
but perhaps some standard protocols might be useful in the future.

Cheers,
Will

📅 Original date posted:2021-12-15 📝 Original message: Hey ...

2023-06-09T13:04:50Z

In reply to nevent1q…g7ft
_________________________

📅 Original date posted:2021-12-15
📝 Original message:
Hey Ronan,

On Wed, Dec 15, 2021 at 05:33:51PM +0000, Ronan McGovern wrote:
>Hi folks, I'm Ronan - based in Dublin and building Trelis.com (simple
>payment links to accept Lightning).
>
>I'm wondering if there is a way to create an invoice that splits the
>payment to two lightning addresses?
>
>If not, what would be required to develop this?
>* A protocol change?
>* Could it be built with the current protocol (I see an app on LN Bits to
>split but it doesn't seem to work).

This is typically done at the application level. The fountain podcasting
app works this way and it seems to work okish.

📅 Original date posted:2021-12-16 📝 Original message: Hey ...

2023-06-09T13:04:50Z

In reply to nevent1q…jt5f
_________________________

📅 Original date posted:2021-12-16
📝 Original message:
Hey Christian,

On Thu, Dec 16, 2021 at 11:27:33AM +0100, Christian Decker wrote:
>This is quite a common request, and we've used a solution I like to call
>the "Poor man's rendez-vous". It basically routes a payment through all
>the parties that are to be paid, with the last one accepting the payment
>for all participants.
>
>The payment is atomic, once the circuit is set up no participant can
>cheat the others and it's seamless from the payer's perspective.
>
>Let's say user `A` wants to pay `B` and `C` atomically. `B` gets 10ksat
>and `C` gets 90ksat out of a total of 100ksat:
>
> 1) `C` creates an invoice with payment hash `H` for 90ksat and sends it
> to `B`
> 2) `B` creates an invoice with payment hash `H` (same as the first
> invoice, but `B` doesn't know the preimage) for 100ksat (maybe plus
> a tiny bit for routing fees between `B` and `C`).
> 3) `A` receives an invoice which appears to be from `B` for the
> expected total of 100ksat.
> 4) `A` proceeds to pay the invoice to `B` like normal
> 5) `B` receives the incoming payment, but doesn't have the preimage for
> `H`, so they must forward to `C` if they want to receive their
> share. `B` then proceeds to pay the 90ksat invoice from `C`, which
> reveals the preimage to them, and they can turn around and claim
> the incoming `100ksat` (covering both `B` and `C` share)
>
>It's a poor man's version because it requires creating two invoices and
>`B` sees two payments (100ksat incoming, 90ksat outgoing), but the
>overall outcome is the desired one: either both parties get paid or
>noone gets paid. This can trivially be extended to any number of parties
>(with reduced success probability), and will remain atomic. It also
>doesn't require any changes on the sender side, and only minimal setup
>between the payees. The crux here is that we somehow need to ensure `H`
>is always the same along the entire chain of payments, but with a good
>coordination protocol that should be feasible.

This is very cool, at least for a small number of parties. When I was
working at a record label it was very common to split between 1-5 people
on a given track, being able to atomically payout to individual artist's
lightning nodes would have been super useful at the time (assuming a
world where our artists ran lightning nodes). At some point I was
testing 600-output bitcoin transactions as a payout method, but that
looked like it was going to be economically infeasible sometime in the
future.

Has anyone coded up a 'Poor man's rendez-vous' demo yet? How hard would
it be, could it be done with a clightning plugin perhaps?

Cheers,
Will

📅 Original date posted:2020-05-14 📝 Original message: ...

2023-06-09T13:00:15Z

In reply to nevent1q…etlh
_________________________

📅 Original date posted:2020-05-14
📝 Original message:
Eugene via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:

> Hello, list,
>
> I haven't closely following the Lightning Network's state of affairs since late 2018 and I wondering, is it possible to support the following use-case with LN:
>
> 1. A user subscribes to the service by opening a channel with it
> 2. User sets his LN node to "trust" invoices that come from said service
> 3. On subscription renewal, service sends an invoice to the client's LN node
> 4. Since the client's node is "trusting" service's node, it pays invoice straight away
>
> User, of course, may cancel the subscription at any time by removing service's LN node public key from the list of "trusted". Or the user can set a limit on the amount and the frequency of payments that would be accepted from the trusted node.
>
> For that matter, the questions are:
>
> 1. Is it possible to send invoices just by LN means? (Should we use TLVs?)
> 2. Is it possible to enable automatic machine-to-machine payments? As in the example above, by accepting invoices from "trusted" nodes.

Offers[0] should support these use cases

Cheers,
Will

[0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002276.html

📅 Original date posted:2018-12-29 📝 Original message: Pavol ...

2023-06-09T12:53:35Z

In reply to nevent1q…7zqx
_________________________

📅 Original date posted:2018-12-29
📝 Original message:
Pavol Rusnak via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
writes:

> Hi all!
>
> Currently, when I perform a payment via QR code, I usually check the
> payee node id (public key) in the send dialog. However, this is a rather
> long hex value, so for example Eclair app shows just the beginning and
> the end of the value.
>
> Idea: Can we show an identicon (for example https://jdenticon.com/) of
> payee node id (= public key) next to the QR code, so user can visually
> quickly check whether the recipient is correct?

I think it would be interesting if someone came up with a visual hashing
algorithm, where small changes in the inputs had uniformly random visual
outputs. I was testing jdenticon with my node id:

03f3c108ccd536b8526841f0a5c58212bb9e6584a1eb493080e7c1cc34f82dad71

I was surprised to see that small changes to the first digit didn't
change the visual output at all. Whether or not this is a useful
property in this use case, it's something to keep in mind.

Cheers,
Will

--
https://jb55.com

📅 Original date posted:2018-08-17 📝 Original message: Hello ...

2023-06-09T12:51:22Z

In reply to nevent1q…485m
_________________________

📅 Original date posted:2018-08-17
📝 Original message:
Hello lightning/bitcoin devs,

I've been working on an OpenGL Lighting Network visualizer written in C
+ nanovg with no dependencies except for glfw. I thought I would release
the alpha here first for testing.

Right now it only parses c-lightning channels and node json, but I'm
currently adding support for LND. I've only tested on linux, so it would
be great if we could get this working on macos/windows as well.

Picture:
Code: https://github.com/jb55/lnvis

How it works
------------

LNvis renders the Lightning Network channel gossip, which include nodes
and the edges (channels) between those nodes.

- Channels are colored by the node that opened the channel
- Channel widths are rendered proportional to the capacity
- Right clicking a node filters the view to that node and its neighbors
- Dragging a node in any view will focus that node and its neihbors

That's about it for now. Next things that I think would be fun to have:

- Filter by alias/id in the UI
- "Google Maps" mode for highlighting potential routes between nodes
- Realtime channel updates from network gossip

Any other ideas and suggesstions would be great.

Contributors welcome!

Cheers,
Will

📅 Original date posted:2018-07-03 📝 Original message: A ...

2023-06-09T12:51:08Z

In reply to nevent1q…h8yx
_________________________

📅 Original date posted:2018-07-03
📝 Original message:
A convention in Haskell libraries is to use an "unsafe" prefix to any function that may have side effects (here be dragons, etc)

I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal this.

📅 Original date posted:2018-01-16 📝 Original message: ...

2023-06-09T12:48:35Z

In reply to nevent1q…20pc
_________________________

📅 Original date posted:2018-01-16
📝 Original message:
Benjamin Mord <ben at mord.io> writes:
> [..]
> why not allow negative fees to incent unwinding, in scenarios where nodes
> consider that cheaper than on-chain rebalancing?

This was brought up before here [1]:

Rusty Russell <rusty at rustcorp.com.au> writes:
>> Edward Marynarz <edziumarynarz at gmail.com> writes:
>> Another trivial question: can the fee be negative? It might help with some
>> channel rebalancing.

>In my original implementation, they could be. However, that turns out
>to be a very strange idea, and complicates routing.

[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-December/000827.html

Cheers,

--
https://jb55.com

📅 Original date posted:2020-05-14 📝 Original message:Orfeas ...

2023-06-07T18:24:21Z

In reply to nevent1q…r8z7
_________________________

📅 Original date posted:2020-05-14
📝 Original message:Orfeas Stefanos Thyfronitis Litos <o.thyfronitis at ed.ac.uk> writes:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
>> If everyone runs such a privately-owned server, on the other hand, this
>> is not so different from having a Lightning node you run at your home
>> that has a fullnode as well and which you access via a remote control
>> mobile device, and it is the inconvenience of having such a server at
>> your home that prevents this in the first place.
>
> Private full nodes serving headers to a handful of weak devices have
> been mentioned many times as a good solution against all sorts of
> problems in a future full of LN + SPV nodes. I agree. It should be
> therefore a top priority to make the UX of connecting my mobile LN
> client to my home full node extremely easy, so that centralised
> services can't improve much on that step. Especially if I already run
> a full node.
>
> Could someone briefly describe how this UX looks currently? And if
> it's not as seamless as it could, what blockers are there?

The UX for this doesn't have to be complicated. All you need is a node
provider like FullyNoded, Casa, etc. My setup at home is a desktop with:

- bitcoind
- clightning
- zerotier (or tailscale) (private vpn for connecting to your node from anywhere)
- sparkwallet (clightning webui) bound to a zerotier interface

So as long as you have a node that runs these bits of software, perhaps
assumeutxo to speed up IBD, and a QR-code automagic setup, then UX
should be pretty smooth. You would still need to deal with lightning
backups and liquidity issues, but we just need to do more work on the
software side to make that experience nicer.

Cheers,
Will

--
https://jb55.com

📅 Original date posted:2019-12-25 📝 Original message:Hey ...

2023-06-07T18:22:06Z

In reply to nevent1q…0fjr
_________________________

📅 Original date posted:2019-12-25
📝 Original message:Hey Chris,

Chris Belcher via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> I've recently been playing around with descriptors, and they are very
> nice to work with. They should become the standard for master public
> keys IMO.
>
> One downside is that users cant easily copypaste them to-and-fro to make
> watch-only wallet. The descriptors contain parenthesis and commas which
> stop highlighting by double-clicking. Also the syntax might look scary
> to newbs.
>
> An obvious solution is to base64 encode the descriptors. Then users
> would get a text blog as the master public key without any extra details
> to bother them, and developers can easily base64 decode for developing
> with them.

I don't think encoding descriptors is a good idea. Encoding makes more
sense if it's non-human-readable binary data that you want transfer over
a plaintext channel.

Descriptors aren't binary data, and have a wealth of useful information
that you can view at a glance. Obfuscating this information just to gain
the ability to copy-paste doesn't seem like a good idea.

> I didn't come up with these ideas, they came from discussions with achow101.

I suggested base58 or base62 +hrp for PSBT in id:87zhzlbfq5.fsf at jb55.com
[1] for the reasons that you mentioned, so I'm a bit sad that base64 was
chosen. base64 isn't really good for double-click copy-pasting, it
contains characters such as +/= which aren't always included when
double-clicking. I prefer bech32, base58 or base62. In this case,
encoding of any kind doesn't make much sense IMO.

Cheers,
Will

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016151.html

--
https://jb55.com

📅 Original date posted:2019-02-17 📝 Original message:Pavol ...

2023-06-07T18:16:29Z

In reply to nevent1q…qfkj
_________________________

📅 Original date posted:2019-02-17
📝 Original message:Pavol Rusnak via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:

> We've been using Protocol buffers in Trezor since the beginning and so
> far it has proven to be as a great choice.
>
> While I agree it is always risky to add an exotic dependency to a
> software project, this one has lots of interoperable implementations in
> all possible languages you can name and it's very easy to work with.
>
> In the past, the Bitcoin dev community used the same arguments with
> regards to PSBT and we ended up with something that is almost as complex
> as protobuf, but it's de-facto proprietary to Bitcoin.
>
> Cherry on top is that PSBT format can be easily translated back and
> forth to PB making it even more obvious that PB should have been used in
> the first place.

One argument against Protobuf is that people are already moving away
from it in favor of FlatBuffers, Google's successor to Protobuf that
doesn't require serialization/deserialization of structures.

Do we really want to be chasing the latest serialization library fad
each time a new one comes out? I do think there is value in having
accessible serialization formats, which is why I think it's a good idea
to provide custom format to protobuf conversion tools.

This way users who prefer not to include large dependencies don't have
to, and protobuf users can just do an extra step to convert it into
their preferred format.

Cheers,
Will

--
https://jb55.com

📅 Original date posted:2018-08-17 📝 Original message:Hello ...

2023-06-07T18:14:06Z

In reply to nevent1q…5gyr
_________________________

📅 Original date posted:2018-08-17
📝 Original message:Hello lightning/bitcoin devs,

I've been working on an OpenGL Lighting Network visualizer written in C
+ nanovg with no dependencies except for glfw. I thought I would release
the alpha here first for testing.

Right now it only parses c-lightning channels and node json, but I'm
currently adding support for LND. I've only tested on linux, so it would
be great if we could get this working on macos/windows as well.

Picture:
Code: https://github.com/jb55/lnvis

How it works
------------

LNvis renders the Lightning Network channel gossip, which include nodes
and the edges (channels) between those nodes.

- Channels are colored by the node that opened the channel
- Channel widths are rendered proportional to the capacity
- Right clicking a node filters the view to that node and its neighbors
- Dragging a node in any view will focus that node and its neihbors

That's about it for now. Next things that I think would be fun to have:

- Filter by alias/id in the UI
- "Google Maps" mode for highlighting potential routes between nodes
- Realtime channel updates from network gossip

Any other ideas and suggesstions would be great.

Contributors welcome!

Cheers,
Will

📅 Original date posted:2018-07-05 📝 Original message:I have ...

2023-06-07T18:13:32Z

In reply to nevent1q…cnnq
_________________________

📅 Original date posted:2018-07-05
📝 Original message:I have another concern with the format. (my original bip comment for some context: [1])

It looks like the one of the reasons I was confused is because you can
only parse the format properly by first deserializing the transaction.
Since there is no "length" field for the key-value map arrays, you must
count the number of transaction input/outputs, and use that as the
number of kv maps to parse.

This is pretty brittle, because now if a Combiner writes the wrong
number of key-value maps that don't align with the number of inputs and
outputs in the transaction, then the psbt will not be able to be
deserialized properly, but is still a valid PSBT. It can't even detect
these situations, because the input and output types share the same enum
values. I don't see anywhere that says the number of key value maps MUST
match the number of inputs/outputs, perhaps it's implied?

I think I think we should either make this explicit in the BIP, add an
array length prefix, or make all (global/input/output) types share the
same enum.

Cheers,
William

[1] https://github.com/bitcoin/bips/pull/694#issuecomment-402812041

📅 Original date posted:2018-07-03 📝 Original message:A ...

2023-06-07T18:13:27Z

In reply to nevent1q…zhcm
_________________________

📅 Original date posted:2018-07-03
📝 Original message:A convention in Haskell libraries is to use an "unsafe" prefix to any function that may have side effects (here be dragons, etc)

I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal this.

📅 Original date posted:2018-06-27 📝 Original message:Hey ...

2023-06-07T18:13:16Z

In reply to nevent1q…9lrk
_________________________

📅 Original date posted:2018-06-27
📝 Original message:Hey Andrew,

If I'm reading the spec right: the way it is designed right now, you
could create hundreds of thousands of zero bytes in the input or output
key-value arrays. As far as I can tell this would be considered valid,
as it is simply a large array of empty dictionaries. Is this right? I'm
worried about buffer overflows in cases where someone sends a large blob
of zeros to an unsuspecting implementation.

Also, the extensibility section reads:

> Additional key-value maps with different types for the key-value pairs
> can be added on to the end of the format.

"different types for the key-value pairs", is this referring to new
types beyond the current global, input and output types?

> The number of each map that follows must be specified in the globals
> section

Is this out of date? Since there is only one type in the global section
now (tx).

> so that parsers will know when to use different definitions of the
> data types

I'm not sure what this means.

Thanks!

Will

--
https://jb55.com

📅 Original date posted:2018-06-26 📝 Original ...

2023-06-07T18:13:12Z

In reply to nevent1q…ukc8
_________________________

📅 Original date posted:2018-06-26
📝 Original message:matejcik via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:

> BIP174 is a ad-hoc format, simple to parse by hand; but that results
> in _having to_ parse it by hand. In contrast, protobuf has a huge
> collection of implementations that will do the job of sorting record
> types into relevant struct fields, proper delimiting of records, etc.

seems a bit overkill for how simple the format is, and pulling in a
large dependency just for this is a bit silly. Although making it
protobuf-compatible is an interesting idea, but I fear would be more
work than is worth? I haven't looked closed enough at the protobuf
encoding to be sure.

> ...while at the same time, implementing "protobuf-based-BIP174" by
> hand is roughly equally difficult as implementing the current BIP174.

as a data point, I was able to build a simple serializer[1] in about an
afternoon. I would much prefer to use this lib in say, clightning (my
original goal), without having to have the larger protobuf dependency.

Cheers,

[1] https://github.com/jb55/libpsbt

--
https://jb55.com

📅 Original date posted:2018-06-23 📝 Original ...

2023-06-07T18:13:10Z

In reply to nevent1q…0zm9
_________________________

📅 Original date posted:2018-06-23
📝 Original message:Achow101 via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:

> I have decided that PSBTs should either be in binary or encoded as a
> Base64 string. For the latter, several Bitcoin clients already support
> Base64 encoding of data (for signed messages) so this will not add any
> extra dependencies like Z85 would.

Since we're still considering the encoding, I wonder if it would be a
good idea to have a human-readible part like lightning invoices[1]?

lightning invoice

vvvvvv
lnbc1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq8rkx3yf5tcsyz3d73gafnh3cax9rn449d9p5uxz9ezhhypd0elx87sjle52x86fux2ypatgddc6k63n7erqz25le42c4u4ecky03ylcqca784w

psbt?

vvvv
psbtcHNidP8BAHwCAAAAAi6MfY03xCfgYOwALsHCvDAZb8L3XWqIRMvANlHAgUMKAQAAAAD/////lqBODMY283eTPj2TrMxif6rNvNtaliTfG0kL0EXyTSwAAAAAAP////8B4CvlDgAAAAAXqRS1O7DcHbjI2APj4594TULkc3/6DYcAAAAAFQEgNzbDwGBTiW1wQc6PW64992zEkUdSIQPIcnzjXxyT6wviFAbumpI8iSGf6cnoUEyDFKaiLRKVwCEDx03HEMQH19tuBB7iEtmFzSgm2T+AbtRJErmh2mkcl3NSrhUB87qKEg2WCuB9Hb5vDDf7TJJtdtUiACCo9ERnvxcdUUmRU+AcC9YpEQn8OL0hs8MiTJ3GtXWQ3yECqPREZ78XHVFJkVPgHAvWKREJ/Di9IbPDIkydxrV1kN9HUiEC6A3sMdFnhlwWhenXqSkeZqTqIsZc/uMkKJoWZ8zaO4chAljLvDyylai+usIzqtx3c5eIBJk3mL5TkKtET23UxTJ+Uq4AAQD9/wACAAAAAYst0vc10KkzivlkAqipHkhBzT/tiCNi5zKfsE8f9lMlAAAAAGpHMEQCIHe+3+qZEMm6TgDeyUHazpdPi0c0mZLF1DEsHPV5bM5VAiBhZOa//3rBFZAGTKVxWDcJM3yKOJc9sucPTp2Ts7zOHQEhAy1kRHRZeE43yy3aNmxpetu9yKrirW23TtLa3jnXWIL6/v///wOCtCoEAAAAABl2qRTaUzZI/TOdV5d5DmuxZn2ehv37aIisgPD6AgAAAAAXqRQgNzbDwGBTiW1wQc6PW64992zEkYcAtMQEAAAAABepFLU7sNwduMjYA+Pjn3hNQuRzf/oNh54vEwAAAQEgAMLrCwAAAAAXqRTzuooSDZYK4H0dvm8MN/tMkm121YcA

Then perhaps you could drop the magic code as well?

Also we could do a base encoding that excludes + and / characters, such
as base62 (gmp-style). It's easier to copy/paste (double clicking a
string stops at / or + in base64 encodings).

example human readible part + base62

psbtWzecLNK5WdwZyceXUYVo0E1TqgLWF0jRXsrLnsuGifjOJl5QHEaaeQbfHfzvbYH85uhUUvpfNc2RYnBqM9E4UqOjzRzDg4QGypL2bxoEsUmmAqOC7nRoN8SuftftuFBI9YabFjVZC9ykOIuJaMzanmKHxnhuh55Hh4mxpwDsvkGFHEHzYHJfkIAiaCEmpdxVBD3qvXNlspDwLKkssUlmDjH7X9zCGyTBE90XvwNdrwM63Q4T45GQbe3c4oQlzCnJuHf5FLnH2oR70hgxIoM01af35iJpZRZAGITtdnKvm9PbH3huEf7TXTzXuNLB9XFh50UlGvnPKcIfFHvgzTSqeN3NmXdzPzsNSRY83BnfHFtTIZnczIyDi5oWsi0sL8f5ABUqGHD61GXDXJGcsqWOjiW6zjhz1L2IKN6OdSVGBFf7C7gH2EYvkWJcKYcJ34gBGsLuXYCU8vzauxEYXXlOXohQ1qKj6Eb0DqOyroRD57uw9fG1e3ueCGlBKmyTI4z4Q1JQXSuLYzBGPlBpVuSZmDBUe28b1EVetJbP9rQ5r6aKsuNX1GToXq1KY5Xh5hsMixJ2o8kG8IBKQSZBRaxjiVEQDWoN3FED869vNHiQtgSLjbqQFZRJuDK0UTMfQCtcg7NdYulPxbUYFNF5Ug6wCvWrTpX1SdbDgGOqZel4ibM18fk9uSIIVDFK9XbenLH3NBOKj0hkxgvrbICZMWBc8GW78TLV4acO75tFBt4a4ziH0wztWGbEEGIAZTDaGmJ51omiRNUVfIX6fO9CeN3Nx3c7Ja2hAjMqQcYcKHEK8tFtLuUdR2jqLuGXOPV4gsqJb8TdkKGEZaA0RRqwHm6HG86OCOEGYqptt43iljv52qkh4znyekJI2mYPItcaw11tsxHaRQcs8Us9Ehlbf6ngmIW6tlo

base64: 920 bytes
base62: 927 bytes

Cheers,

[1] https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md#human-readable-part

--
https://jb55.com

📅 Original date posted:2017-11-17 📝 Original message:Bryan ...

2023-06-07T18:07:49Z

In reply to nevent1q…8zcs
_________________________

📅 Original date posted:2017-11-17
📝 Original message:Bryan Bishop via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:

> It's not clear to me if you are have looked at the previous UTXO set
> commitment proposals.
>
> some utxo set commitment bookmarks (a little old)
> http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt
>
> TXO bitfields
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08-bram-cohen-merkle-sets/
>
> delayed TXO commitments
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html
>
> TXO commitments do not need a soft-fork to be useful
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html
>
> rolling UTXO set hashes
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
>
> lotta other resources available, including source code proposals..

Thanks!

Has anyone categoried list discussions by topic like this? It seems a
lot of this stuff is scattered between mailing lists, irc conversations,
etc and can be hard to know whats floating out there.

--
https://jb55.com