Zac -- this is kind of offtopic for this thread, which is primarily to do
with making software/standards that supports existing practices in the
bitcoin community rather than new standards/formats for a similar task.
I think there have been some other related posts recently where it might be
more
> 1. More data allowed in scriptSig, e.g. 80 byte payload (81 actually, I
> think) for OP_RETURN versus 40 bytes for a BIP141 payload.
> Maximizing payload size better amortizes the overhead cost of the
> containing transaction and the output's nValue field.
In order to reduce the footprint
I guess in the interest of being clear; I don't particularly want a
OP_RETURN address either, they're just annoying to program around, and they
exist historically, as well as perhaps in the future.
Maybe people will start using the annex space to add any metadata required?
E.g. stealth addresses.
On Sat, Apr 24, 2021 at 01:05:25PM -0700, Jeremy wrote:
> I meant the type itself is too wide, not the length of the value. As in
> Script can represent things we know nothing about.
I guess I still don't understand your concern, then. If script can
represent things we know nothing about, then s
Inline responses
On Fri, Apr 23, 2021, 11:18 AM David A. Harding wrote:
> On Tue, Apr 20, 2021 at 08:46:07AM -0700, Jeremy via bitcoin-dev wrote:
>
>
>
>
>
> * > Script is technically "too wide" a type as what I really want is to >
> only return coins with known output types. I don't understand
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.
If block compression is going to be considered, zstd provides better
properties than the competition.
Especially for the decompression. [1]
[1] https://github.com/facebook/zstd
--
Best Regards / S pozdravom,
Pavol "stick" Rusnak
Co-founder and CTO, SatoshiLabs
__
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
What is preventing the BIP maintainership role from moving to a bot? It does seem like a bot should be able to do a fine
job given the explicit criteria (though ignoring obvious spam is often nice, its by no means a requirement).
Given recent events where humans haveacted like humans, it see
ACK adding Kalle
On Fri, Apr 23, 2021 at 5:51 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi Luke,
>
> For the records and the subscribers of this list not following
> #bitcoin-core-dev, this mail follows a discussion which did happen during
> yesterday irc
I have created three additional BIPs that are associated with my recent
proposals. They can be found here:
https://github.com/cgilliard/bips/blob/notification/bip-.mediawiki
and here:
https://github.com/cgilliard/bips/blob/moderation/bip-.mediawiki
and here:
https://github.com/cgilliar
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
___
bi
12 matches
Mail list logo
