From: Peter Todd <pete@petertodd•org>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
Date: Sun, 2 Jun 2013 14:41:13 -0400 [thread overview]
Message-ID: <20130602184113.GA19604@savin> (raw)
In-Reply-To: <CAJHLa0OEUfsZX5caF-urE+Tu9tpgf9xuVjskfoEC8nXO2yZ4ow@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]
On Sun, Jun 02, 2013 at 01:35:10PM -0400, Jeff Garzik wrote:
> It is a fair criticism that this inches the incentives, a bit, towards
> timestamping and other non-currency uses. But those uses (a) cannot
> be prevented and (b) have already been automated anyway (e.g. the
> python upload/download tools stored in-chain).
Yeah, and Bitcoin sacrifices are kind of an odd middle ground there.
It's been suggested to make provably unspendable OP_RETURN IsStandard()
only if the txout value is zero, but considering the sacrifice use-case
I'm thinking we should allow people to throw away coins in a
non-UTXO-bloating way if they choose too.
> I do think the overwhelming majority of users are invested in
> bitcoin-the-currency (or bitcoin-the-commodity, take your pick), i.e.
> the value proposition. That's our 98% use case. Given the relative
> volumes of traffic, timestamping/data storage/messaging is essentially
> getting a free ride. So IMO it is worth continuing to explore
> /disincentives/ for use of the blockchain for data storage and
> messaging, for the rare times where a clear currency-or-data-storage
> incentive is available.
Indeed, just recognize that those disincentives must be implemented in a
way that makes doing the less-harmful thing is to your advantage. For
instance people keep arguing for OP_RETURN to only be allowed as one
txout in a tx, which puts it at a disadvantage relative to just using
unspendable outputs. Similarly because people can play OP_CHECKMULTISIG
games, allow as much data as can be included in that form, 195 bytes.
Of course, you can't block everything:
----- Forwarded message from aitahk2l <aitahk2l@tormail•org> -----
Date: Sun, 02 Jun 2013 02:40:10 +0100
From: aitahk2l <aitahk2l@tormail•org>
To: pete@petertodd•org
Subject: Your timestamper
We spoke a few months back and I sent you some funds to run your
timestamper.
I'm letting you know we're going back to unspendable txout timestamps
for our needs. Your service is great, but I think you have written it
prematurely. Like you said in your recent bitcoin-development post on
sacrifices if the technology enables a use, people will use it.
Inefficient timestamping is one such use and threatens the blockchain
with unlimited bloat, but from what I hear from Gavin he doesn't see
decentralization as particularly important.
You really should turn off your OpenTimestamps servers. They mislead
people into a sense of scalability that just isn't there. You'll see
some of our efforts at 1MBGavinWuiJCF6thGfEriB2WhDD5nhB2a soon;
frankly I think he is the biggest threat Bitcoin faces in the long
term and will back us all into a scalability corner with no good
solutions.
Feel free to forward this message to others.
----- End forwarded message -----
Seems legit - traffic on my timestamper is significantly reduced from
what it was before. Incidentally, I've left the opentimestamps client
deliberately broken for months now to see if anyone used it, and other
than this guy I've had zero bug reports.
--
'peter'[:-1]@petertodd.org
0000000000000046da2c6f02bf57f3bdc48a08388e0030fc4490f5fc048516e6
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-06-02 18:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-01 19:30 Peter Todd
[not found] ` <201306012034.31543.luke@dashjr.org>
2013-06-01 20:58 ` Peter Todd
[not found] ` <38A06794-B6B4-45F3-99C1-24B08434536D@gmail.com>
2013-06-02 6:13 ` Peter Todd
2013-06-02 17:35 ` Jeff Garzik
2013-06-02 18:41 ` Peter Todd [this message]
2013-06-04 0:22 ` Mark Friedenbach
2013-06-02 21:45 ` Adam Back
2013-06-04 14:12 ` Jeff Garzik
2013-06-04 14:55 ` John Dillon
2013-06-04 17:42 ` Jeff Garzik
2013-06-04 18:36 ` Roy Badami
2013-06-04 18:49 ` Jeff Garzik
2013-06-04 20:25 ` Peter Todd
2013-06-03 23:43 ` Melvin Carvalho
2013-06-04 2:26 ` Michael Hendricks
2013-06-06 19:14 Luke-Jr
2013-06-06 19:59 ` Andreas M. Antonopoulos
2013-06-06 20:07 ` Luke-Jr
2013-06-06 20:16 ` Andreas M. Antonopoulos
2013-06-06 21:48 ` Luke-Jr
2013-06-06 22:10 ` Melvin Carvalho
2013-06-06 20:25 ` Melvin Carvalho
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=20130602184113.GA19604@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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