Nostr notes by William Casarin [ARCHIVE]

📅 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: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