1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <luke@dashjr.org>) id 1UkgTQ-0006wR-2k
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 20:07:52 +0000
X-ACL-Warn:
Received: from zinan.dashjr.org ([173.242.112.54])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1UkgTO-0002xn-PM for bitcoin-development@lists.sourceforge.net;
Thu, 06 Jun 2013 20:07:52 +0000
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:222:4dff:fe50:4c49])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id BE5E527A2965;
Thu, 6 Jun 2013 20:07:44 +0000 (UTC)
From: "Luke-Jr" <luke@dashjr.org>
To: "Andreas M. Antonopoulos" <andreas@rooteleven.com>
Date: Thu, 6 Jun 2013 20:07:38 +0000
User-Agent: KMail/1.13.7 (Linux/3.9.4-gentoo; KDE/4.10.2; x86_64; ; )
References: <201306061914.20006.luke@dashjr.org>
<CAFmyj8zG7iLnwm7iUwxyOXTe3SZxAOFoZdy3=oRa2WqYbiWsHQ@mail.gmail.com>
In-Reply-To: <CAFmyj8zG7iLnwm7iUwxyOXTe3SZxAOFoZdy3=oRa2WqYbiWsHQ@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201306062007.41398.luke@dashjr.org>
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1UkgTO-0002xn-PM
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal: soft-fork to make
anyone-can-spend outputs unspendable for 100 blocks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2013 20:07:52 -0000
On Thursday, June 06, 2013 7:59:16 PM Andreas M. Antonopoulos wrote:
> Is there any consideration given to the fact that bitcoin can operate as a
> platform for many other services, if it is able to be neutral to payload,
> as long as the fee is paid for the transaction size?
This doesn't work like you might think: first of all, the fees today are
greatly subsidized - the actual cost to store data in the blockchain is much
higher than most storage solutions. Secondly, only the miner receives the
fees, not the majority of nodes which have to bear the burden of the data.
That is, the fee system is setup as an antispam/deterrant, not as payment for
storage.
> Unless I have misunderstood this discussion, it seems to me that this is a
> bit like saying in 1990 "IP Is only for email, the majority of users want
> email, we shouldn't allow video, voice or images". Ooops, there goes the
> web.
Not the same thing at all; nobody is forced to store/relay video/voice/images
without reimbursement. On the other hand, any full Bitcoin node is required to
at least download the entire blockchain once. And the network as a whole
suffers if nodes decide to start not-storing parts of the blockchain they
don't want to deal with.
> Is it possible to solve this by solving the issue of provably un-spendable
> outputs without foreclosing on the possibility of other types of
> transaction payloads (ie, not money), that would open the possibility for a
> myriad of layered apps above? For example, hashes of content that is
> external to bitcoin, that people want to pay to have timestamped in the
> blockchain, as provably unspendable outputs.
This is how merged mining solves the problem. A single extra hash in the
coinbase can link the bitcoin blockchain up with unlimited other data.
> The social compact is to accept transaction for fee. I think it is a major
> mistake to make decisions that discriminate on the content of the
> transaction, saying that some uses are not appropriate. If the fee is paid
> and it covers the size of the transaction, why would it matter if it is not
> a payment?
See above.
> I could be totally misreading this thread, too, so please allow me some
> slack if I have!
>
> On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr <luke@dashjr.org> wrote:
> > On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> > > scriptPubKey: <data> OP_TRUE
> > >
> > > ...
> > > Along with that change anyone-can-spend outputs should be make
> >
> > IsStandard()
> >
> > > so they will be relayed.
> >
> > Data does not belong in the blockchain. People running nodes have all
> > implicitly agreed to store the blocks for financial purposes, and storing
> > data
> > is a violation of that social contract. Proof-of-stake may be arguably
> > financial, but I'm sure there must be a way to do it without spamming
> > people
> > against their consent.
> >
> > > The alternative is sacrifices to unspendable outputs, which is very
> > > undesirable compared to sending the money to miners to further
> > > strengthen the security of the network.
> >
> > The alternative is to make other standard outputs unable to store data as
> > well.
> >
> > Luke
> >
> >
> > -------------------------------------------------------------------------
> > ----- How ServiceNow helps IT people transform IT departments:
> > 1. A cloud service to automate IT design, transition and operations
> > 2. Dashboards that offer high-level views of enterprise services
> > 3. A single system of record for all IT processes
> > http://p.sf.net/sfu/servicenow-d2d-j
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
