From: Lautaro Dragan <lautarodragan@gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Claiming an OP_RETURN Prefix
Date: Wed, 15 Aug 2018 23:22:21 -0300 [thread overview]
Message-ID: <CAK6DEso4-R78qLtQLfGxNUML5B1Y8gxXXVzrzmSwkPabMfkW+w@mail.gmail.com> (raw)
In-Reply-To: <201808160106.54960.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]
Thanks Christopher.
> op_return outputs can be pruned because they are not spendable.
putting a hash on in the witness script data won't make things better
(it would actually make them worse) and it definitely doesn't help
"block size bloat".
Agreed
> I think I'm missing some context, but if you're using op_return purely
for timestamping I would recommend using pay 2 contract instead.
And
> If you're *actually* just doing timestamping you're better off using
OpenTimestamps. But many times people think they're just doing timestamping
in reality mere timestamps are insufficient for the task.
No, it's not only timestamping. Think of it as storing the URL of something
in the OP_RETURN, only that instead of a URL it's a hash. But it's not just
the hash of the work — IPFS adds a few other elements that affect this
hash, so calculating it out of the file being added won't do. Also, the
batching OTS uses and the batching we use (using IPFS directories) are
incompatible.
> Can a miner identify which transactions came from your software simply by
running a copy themselves? If so, then they can censor your transactions
no matter how you encode them.
Miners would have to try and `ipfs cat` every OP_RETURN of every
transaction (maybe filtering by byte length), which is a relatively high
cost operation. But such a script is straight forward to write and can be
hosted in a cheap AWS machine. We're talking about less than a week of
coding and less than a hundred bucks of hosting, so if they're out to get
you it won't make a difference.
> Choosing not to mine transactions is not censorship.
Is it not, if for political rather than economical reasons? These
transactions pay fees like any other.
El mié., 15 de ago. de 2018 a la(s) 22:08, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> escribió:
> On Wednesday 15 August 2018 21:54:50 Christopher Allen via bitcoin-dev
> wrote:
> > On Wed, Aug 15, 2018 at 2:24 PM Jude Nelson via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> > > Can a miner identify which transactions came from your software simply
> by
> > > running a copy themselves? If so, then they can censor your
> transactions
> > > no matter how you encode them.
> >
> > Possibly, but in the IPFS case I suspect the latency required to inspect
> > all hashes would likely impact the ability of the miner to succeed in
> the
> > block. (True? I don’t touch mining software.)
>
> Not true at all.
>
> > Thus as long as all hashes look the same, and there are multiple content
> > addressable schemes that use hashes that have to be searched in order to
> > know to censor, you have to censor all or none.
>
> Choosing not to mine transactions is not censorship.
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5510 bytes --]
next prev parent reply other threads:[~2018-08-16 2:22 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 18:34 [bitcoin-dev] Claiming an OP_RETURN Prefix Christopher Allen
2018-08-15 20:33 ` Jorge Timón
2018-08-15 20:40 ` Jude Nelson
2018-08-15 21:54 ` Christopher Allen
2018-08-16 1:06 ` Luke Dashjr
2018-08-16 2:22 ` Lautaro Dragan [this message]
2018-08-16 2:37 ` Luke Dashjr
2018-08-16 17:32 ` Ryan Grant
2018-08-15 21:46 ` Peter Todd
-- strict thread matches above, loose matches on Subject: below --
2018-08-05 21:11 Lautaro Dragan
2018-08-05 23:57 ` Peter Todd
2018-08-06 0:55 ` Lautaro Dragan
2018-08-06 1:54 ` CryptAxe
2018-08-06 2:04 ` Luke Dashjr
2018-08-06 2:19 ` Lautaro Dragan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK6DEso4-R78qLtQLfGxNUML5B1Y8gxXXVzrzmSwkPabMfkW+w@mail.gmail.com \
--to=lautarodragan@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lautaro.dragan@gmail.com \
--cc=luke@dashjr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox