Greg Maxwell [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 22:52:21

- reply

📅 Original date posted:2021-04-24
📝 Original message:https://bitcointalk.org/index.php?topic=5303978.msg55946632#msg55946632
Blockstream satellite codebase includes an alternative serialization
that works a single transaction at a time and saves ~20%. This avoids
violating layering, preserves single txn access, is compatible with
transaction relay. (and if you wanted could also be fed to a
multiple txn at a time compressor for additional savings). This
format makes intelligent use of the entirety of the transaction
format, not just amount encodings but even optimizing predictable
hashes (e.g. for p2sh embedded segwit) -- achieving savings that *no*
generic compressor could ever achieve.
Most of the savings from generic compressors comes from repeated
pubkeys and addresses, so it's highly variable, depends on address
reuse, and will likely be diminished by taproot (due to shrinking
multisig) and very much reduced by signature aggregation in the
future.
If you're thinking about use across networks generic compression
interfaces like zlib have had a pretty disappointing security track
record.
If you search the list archive and bitcoin-core github you'll find
many prior discussions of using generic compressors.
On Sat, Apr 24, 2021 at 6:12 PM NITSOPOULOS KONSTANTINOS via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi, I can compress new blocks by up to 18% using the 7z file type. I use wxHexEditor to dump a block's raw hex onto my disk, and then compress that with 7-Zip. I'd like to see 7z built into Bitcoin Core, for block compression (storage & propagation). The entire blockchain could be under 290GB if it's converted into a 7z archive-chain ("7z-chain"). I can compress some recent example blocks (hex -> less hex) if anyone wants. A future BIP could try increase the block Weight Units limit by up to 21% if 7z blocks are smaller & quick.
>
> Programming compression seems too difficult for me, so I'm hoping somebody else does it!
>
> Eventually I think transactions can be compressed by replacing addresses (& public keys) and coins, wherever possible, with just their own unique sequential index. TX amounts can also be compressed if they contain only a decimal digit or two, e.g. 00000000.10000000 XBT. A TX of 0.1 XBT between two existing addresses could be somehow compressed to half or maybe a quarter of its current size!
>
> -Tinos
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:52:11

- reply

📅 Original date posted:2021-04-26
📝 Original message:I endorse Harding's recommendations. On the point about mirroring,
one thing to keep in mind is that the other repositories may go
offline.
Modification confusion could be avoided by recording what revision
(commit hash) was current at the time of inclusion, but the document
going offline can only be protected against by maintaining a copy
somewhere.
On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote:
> > In general, I think its time we all agree the BIP process has simply failed
> > and move on. Luckily its not really all that critical and proposed protocol
> > documents can be placed nearly anywhere with the same effect.
>
> I recommend:
>
> 1. We add additional BIP editors, starting with Kalle Alm (if there are
> no continuing significant objections).
>
> 2. We seek Luke Dashjr's resignation as BIPs editor.
>
> 3. We begin treating protocol documents outside the BIPs repository as
> first-class BIP documentation.
>
> The first recommendation permits continued maintenance of existing BIPs
> plus gives the additional maintainers an opportunity to rebuild the
> credibility of the repository.
>
> The second recommendation addresses the dissatisfaction of many BIP
> authors and potential authors with the current editor, which I think
> will discourage many of them from making additional significant
> contributions to the repository. It also seems to me to be a better use
> of Luke's talents and interests for him to focus on protocol research
> and review rather than procedurally checking whether a bunch of
> documents are well formed.
>
> The third recommendation provides an escape hatch for anyone, such as
> Matt, who currently thinks the process has failed, or for anyone who
> comes to that same conclusion in the future under a different editing
> team. My specific recommendations there are:
>
> a. Anyone writing protocol documentation in the spirit of the BIP
> process can post their idea to this mailing list like we've always
> done and, when they've finished collecting initial feedback, they can
> assign themselves a unique decentralized identifier starting with
> "bip-". They may also define a shorter alias that they encourage
> people to use in cases where the correct document can be inferred
> from context. E.g.,
>
> bip-wuille-taproot (bip-taproot)
> bip-towns-versionbits-min-activation-height (bip-vbmah)
> bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf)
>
> b. The author then publishes the document to any place they'd like, although
> they are strongly encouraged to make any document source available
> under an open license to ensure others can create their own
> modifications.
>
> c. Implementations of BIPs, whether original repository BIPs or
> decentralized BIPs, link to the BIPs they implement to ensure
> researchers and developers can find the relevant protocol
> documentation. E.g.,
> https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md
>
> (It may also be advisable for implementations to mirror copies of
> the BIPs they implement so later modifications to the document
> don't confuse anyone. For this reason, extremely liberal
> licensing of BIP documents is encouraged.)
>
> d. To help maintain quality and consistency between documentation, the
> BIP editors provide a BIP document template, guidelines similar to
> the existing BIP2, and an easy-to-run format linter.
>
> I think this decentralized BIPs alternative also helps address some
> longstanding problems with the BIPs system: that many casual Bitcoin
> users and developers think of documents in the BIPs repo as
> authoritative and that there are some development teams (such as for LN)
> that have already abandoned the BIPs process because, in part, they want
> complete control over their own documentation.
>
> The recommendations above were developed based on conversations I had
> with a few stakeholders in the BIPs process, but I did not attempt a
> comprehensive survey and I certainly don't claim to speak for anyone
> else. I hope the recommendations are satisfactory and I look forward to
> your feedback.
>
> Thanks,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 22:52:05

- reply

📅 Original date posted:2021-04-24
📝 Original message:I am opposed to the addition of Kalle Alm at this time.
Those who believe that adding him will resolve the situation with
Luke-jr's inappropriate behavior re: PR1104 are mistaken.
27e59ffd51ee5a95d0e0faff70e045faca10b00015e90abc1c8de48b1dfff40c