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
139
140
141
142
143
144
145
146
147
148
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimonmv@gmail.com>) id 1UFhrG-0006uz-GV
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 09:20:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.50 as permitted sender)
client-ip=209.85.216.50; envelope-from=jtimonmv@gmail.com;
helo=mail-qa0-f50.google.com;
Received: from mail-qa0-f50.google.com ([209.85.216.50])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFhrD-0007V8-HF
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 09:20:26 +0000
Received: by mail-qa0-f50.google.com with SMTP id dx4so503410qab.16
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 02:20:18 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.49.84.6 with SMTP id u6mr6879123qey.35.1363166417968; Wed,
13 Mar 2013 02:20:17 -0700 (PDT)
Received: by 10.49.11.140 with HTTP; Wed, 13 Mar 2013 02:20:17 -0700 (PDT)
In-Reply-To: <CADb9v0JMy8_rWfU3j-g74cbh_1wAdCa5Ce+PkzGadbZL+OV4VQ@mail.gmail.com>
References: <20130310043155.GA20020@savin> <20130312074945.GB25250@savin>
<CADb9v0JMy8_rWfU3j-g74cbh_1wAdCa5Ce+PkzGadbZL+OV4VQ@mail.gmail.com>
Date: Wed, 13 Mar 2013 10:20:17 +0100
Message-ID: <CABOyFfrPTYeq-g5tgte2HWfvBiBcRLw_Bvyk_X2hXMWVoW3dgQ@mail.gmail.com>
From: =?ISO-8859-1?B?CUpvcmdlIFRpbfNu?= <jtimonmv@gmail.com>
To: Stephen Pair <stephen@bitpay.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(jtimonmv[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1UFhrD-0007V8-HF
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
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: Wed, 13 Mar 2013 09:20:26 -0000
I'm not sure I understand your proposal, but its sounds good.
Can you elaborate with an example?
Are you considering colored coins/smart property?
On 3/13/13, Stephen Pair <stephen@bitpay.com> wrote:
> Instead of thinking in terms of blocking uneconomical transactions (how
> would a node even determine what's economical?), what about thinking in
> terms of paying for a feed of economical (i.e. profitable) transactions?
> There is a market for fee bearing, profitable transactions...if there is =
no
> one willing to pay to receive a transaction, then no one will bother
> propagating it. Such a system would make it possible to determine the
> probability of confirmation in a given timeframe for a given fee.
>
>
> On Tue, Mar 12, 2013 at 3:49 AM, Peter Todd <pete@petertodd.org> wrote:
>
>> On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote:
>> > As discussed endlessly data in the UTXO set is more costly, especially
>> > in the long run, than transaction data itself. The fee system is per K=
B
>> > in a block, and thus doesn't properly capture the long-term costs of
>> > UTXO creation.
>>
>> There's been a lot of discussion about this issue, and many people have
>> asked that Bitcoin not arbitrarily block interesting potential uses of
>> provably unspendable txouts for data applications, and similarly
>> spendable txouts representing assets. I've changed my hardline position
>> and now think we should support all that stuff. However, there is one
>> remaining class of txout not yet talked about, unspendable but not
>> provably so txouts. For instance we could make the following a standard
>> transaction type:
>>
>> scriptPubKey: OP_HASH160 <20 byte digest> OP_EQUALVERIFY <data>
>> scriptSig: <data>
>>
>> Of course, usually the 20 byte digest would be picked randomly, but it
>> might not be, and thus all validating nodes will always have a copy of
>> the data. With the 10KB limit on script sizes you can fit 9974 bytes of
>> data per transaction output with very little waste.
>>
>> A good application is timestamping, with the advantage over
>> coinbase/merkle tree systems in that you don't have to wait until your
>> timestamp confirms, or even store the timestamp at all. Another
>> application, quite possible with large block sizes and hence cheap or
>> free transactions, is secure data backups. In particular such a service,
>> perhaps called Google Chain Storage, can offer the unique guarantee that
>> you can know you're data is secure by simply performing a successful
>> Bitcoin transaction.
>>
>> --
>> 'peter'[:-1]@petertodd.org
>>
>>
>> ------------------------------------------------------------------------=
------
>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>> endpoint security space. For insight on selecting the right partner to
>> tackle endpoint security challenges, access the full report.
>> http://p.sf.net/sfu/symantec-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> Stephen Pair, Co-Founder, CTO
>
> Does *your* website accept cash? bitpay.com
>
> [image: bitpay-small]
>
> ABC6 C11B BF75 9E2B FC6A B3E0 7B96 40B2 CAC0 C158
>
--=20
Jorge Tim=F3n
http://freico.in/
http://archive.ripple-project.org/
|
