What is Nostr?
Zac Greenwood [ARCHIVE] /
npub1gym…vff7
2023-06-07 23:04:53
in reply to nevent1q…zs3k

Zac Greenwood [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-24 📝 Original message:Hi ZmnSCPxj, Any benefits ...

📅 Original date posted:2022-02-24
📝 Original message:Hi ZmnSCPxj,

Any benefits of my proposal depend on my presumption that using a standard
transaction for storing data must be inefficient. Presumably a transaction
takes up significantly more on-chain space than the data it carries within
its OP_RETURN. Therefore, not requiring a standard transaction for data
storage should be more efficient. Facilitating data storage within some
specialized, more space-efficient data structure at marginally lower fee
per payload-byte should enable reducing the footprint of storing data
on-chain.

In case storing data through OP_RETURN embedded within a transaction is
optimal in terms of on-chain footprint then my proposal doesn’t seem useful.

Zac

On Fri, 25 Feb 2022 at 01:05, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Zac,
>
> > Reducing the footprint of storing data on-chain might better be achieved
> by *supporting* it.
> >
> > Currently storing data is wasteful because it is embedded inside an
> OP_RETURN within a transaction structure. As an alternative, by supporting
> storing of raw data without creating a transaction, waste can be reduced.
>
> If the data is not embedded inside a transaction, how would I be able to
> pay a miner to include the data on the blockchain?
>
> I need a transaction in order to pay a miner anyway, so why not just embed
> it into the same transaction I am using to pay the miner?
> (i.e. the current design)
>
>
>
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220225/6ee277d1/attachment.html>;
Author Public Key
npub1gymmksd9tgwzc5w33umlx08sc2ggys3v2cucmpvl7yy9720wh49s8dvff7