Re: [bitcoin-dev] Future of the bitcoin-dev mailing list

[William Casarin via bitcoin-dev]

On Tue, Nov 07, 2023 at 06:14:23PM +, Andrew Chow via bitcoin-dev wrote:

Hi Dan,

I don't think nostr would be a suitable replacement for the mailing
list, although this opinion is biased by the fact that I do not use
nostr and find it to be uninteresting.


email-like functionality over nostr isn't really explored yet, but it is
something I'm interesting in. So I agree nostr isn't a suitable email
replacement *yet*.


From my limited understanding of how nostr works, it's not clear to me
how a distributed system that uses message broadcast would work in the
same way as a mailing list.


My idea was to have a mailing list relay, the only thing missing is To:
and Cc: tags on notes so that the relay can reject notes not destined
for the mailing list


How would people "subscribe"? How would archives be searched or
otherwise be available to people who are not on nostr?


You would subscribe by connecting to the relay and pulling down the
notes. your client could cache notes and only pull new ones.


How do you distinguish and filter between legitimate dev posts
intended for discussion and random crap and shitposting as shows up on
social media?


You would need to have metadata on the note that specifies that the note
is destined for that specific mailing list relay (To, Cc, etc). Then the
client sending the message can send it to that specific relay during
note composition. Again, this is different than then current model that
exists with social networking clients designed for blasting your note to
as many people as possible.


I also don't think that long form text on nostr (or any similar
platform) can sufficiently replace email. None of these things seem to
contain a way to have a separate subject line as email does. Subjects
are immensely important for me as it provides a quick and easy way to
filter out things I don't care about reading. I don't want to have read
something in before I can decide that I don't care about reading it.


Subject lines already exist in nostr and are a part of some email-like
clients like https://github.com/unclebob/more-speech . it's just a tag
like every other piece of metadata.


In general, I strongly prefer email, or a platform that has email as a
first class user interface, over platforms such as nostr, matrix, or web
forums. Email is universal - everyone has one and everyone knows how it
works. It dramatically lowers the barrier of entry. Having to make an
account somewhere or download some specific client in order to
participate will simply result in only the most dedicated participating.
Development in open source must be an open process and the barriers to
entry should be low.


I definitely prefer email at the moment as well, but it is also a pain
in the ass to run email infra. As someone who runs both email servers
and nostr relays I can say nostr is much more pleasant.

So yeah, it's a bit too early for a nostr replacement, but it's
definitely possible, and you get proper cryptographic identities and
schnorr signed notes which is a bonus. For dealing with spam you could
have a sat entrance fee via lightning. I will start looking into this!

Cheers,

Will
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] On the scalability issues of onboarding millions of LN mobile clients

[William Casarin via bitcoin-dev]

Orfeas Stefanos Thyfronitis Litos  writes:
> ZmnSCPxj via Lightning-dev  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Base64-encoded descriptors

[William Casarin via bitcoin-dev]

Hey Chris,

Chris Belcher via bitcoin-dev  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@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References

[William Casarin via bitcoin-dev]

Hello Mike,

Mike Brooks via bitcoin-dev 
writes:

> Motivation
>
> Giving scripts the ability to refer to data on the blockchain will reduce
> transaction sizes because key material does not have to be repeated in
> every Script. Users of the network are rewarded with smaller transaction
> sizes, and miners are able to fit more transactions into new blocks.
> Pointers are a common feature and it felt like this was missing from
> Bitcoin Script.

This would incentivize address re-use which would be bad for
fungibility. It appears you're trying to optimize a use case which is
already discouraged :(

Cheers,
Will

-- 
https://jb55.com
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] NIH warning (was Re: [BIP Proposal] Simple Proof-of-Reserves Transactions)

[William Casarin via bitcoin-dev]

Pavol Rusnak via bitcoin-dev 
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] [announce] LNvis alpha - A Lightning Network Visualizer

[William Casarin via bitcoin-dev]

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: https://jb55.com/s/abe49a248360d41c.png
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 174 thoughts

[William Casarin via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[William Casarin via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 174 thoughts

[William Casarin via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 174 thoughts

[William Casarin via bitcoin-dev]

matejcik via bitcoin-dev  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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 174 thoughts

[William Casarin via bitcoin-dev]

Achow101 via bitcoin-dev  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 

  vv
  
lnbc1pvjluezpp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdpl2pkx2ctnv5sxxmmwwd5kgetjypeh2ursdae8g6twvus8g6rfwvs8qun0dfjkxaq8rkx3yf5tcsyz3d73gafnh3cax9rn449d9p5uxz9ezhhypd0elx87sjle52x86fux2ypatgddc6k63n7erqz25le42c4u4ecky03ylcqca784w

psbt?

  
  
psbtcHNidP8BAHwCAi6MfY03xCfgYOwALsHCvDAZb8L3XWqIRMvANlHAgUMKAQD/lqBODMY283eTPj2TrMxif6rNvNtaliTfG0kL0EXyTSwAAP8B4CvlDgAXqRS1O7DcHbjI2APj4594TULkc3/6DYcAFQEgNzbDwGBTiW1wQc6PW64992zEkUdSIQPIcnzjXxyT6wviFAbumpI8iSGf6cnoUEyDFKaiLRKVwCEDx03HEMQH19tuBB7iEtmFzSgm2T+AbtRJErmh2mkcl3NSrhUB87qKEg2WCuB9Hb5vDDf7TJJtdtUiACCo9ERnvxcdUUmRU+AcC9YpEQn8OL0hs8MiTJ3GtXWQ3yECqPREZ78XHVFJkVPgHAvWKREJ/Di9IbPDIkydxrV1kN9HUiEC6A3sMdFnhlwWhenXqSkeZqTqIsZc/uMkKJoWZ8zaO4chAljLvDyylai+usIzqtx3c5eIBJk3mL5TkKtET23UxTJ+Uq4AAQD9/wACAYst0vc10KkzivlkAqipHkhBzT/tiCNi5zKfsE8f9lMlAGpHMEQCIHe+3+qZEMm6TgDeyUHazpdPi0c0mZLF1DEsHPV5bM5VAiBhZOa//3rBFZAGTKVxWDcJM3yKOJc9sucPTp2Ts7zOHQEhAy1kRHRZeE43yy3aNmxpetu9yKrirW23TtLa3jnXWIL6/v///wOCtCoEABl2qRTaUzZI/TOdV5d5DmuxZn2ehv37aIisgPD6AgAXqRQgNzbDwGBTiW1wQc6PW64992zEkYcAtMQEABepFLU7sNwduMjYA+Pjn3hNQuRzf/oNh54vEwAAAQEgAMLrCwAXqRTzuooSDZYK4H0dvm8MN/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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Protocol-Level Pruning

[William Casarin via bitcoin-dev]

Bryan Bishop via bitcoin-dev 
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev