diff options
| author | Luke-Jr <luke@dashjr.org> | 2013-06-06 20:07:38 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2013-06-06 20:07:52 +0000 |
| commit | 085cd0e37c75720a2094fabf32df61dbc1ed878e (patch) | |
| tree | 1031a75e064114d1fa7ec3e7178b03bef8721a6a | |
| parent | 307ba271eb7e9aed93e3251b7c6cd185b7aa9df0 (diff) | |
| download | pi-bitcoindev-085cd0e37c75720a2094fabf32df61dbc1ed878e.tar.gz pi-bitcoindev-085cd0e37c75720a2094fabf32df61dbc1ed878e.zip | |
Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks
| -rw-r--r-- | f7/85c0b58730f1a7a7f68394df19f503a9df1159 | 138 |
1 files changed, 138 insertions, 0 deletions
diff --git a/f7/85c0b58730f1a7a7f68394df19f503a9df1159 b/f7/85c0b58730f1a7a7f68394df19f503a9df1159 new file mode 100644 index 000000000..38accd982 --- /dev/null +++ b/f7/85c0b58730f1a7a7f68394df19f503a9df1159 @@ -0,0 +1,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 + + |