From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wd5cN-00026V-1h for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 22:26:15 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.51 as permitted sender) client-ip=209.85.216.51; envelope-from=tier.nolan@gmail.com; helo=mail-qa0-f51.google.com; Received: from mail-qa0-f51.google.com ([209.85.216.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wd5cL-0000hI-Ui for bitcoin-development@lists.sourceforge.net; Wed, 23 Apr 2014 22:26:15 +0000 Received: by mail-qa0-f51.google.com with SMTP id j7so1512076qaq.10 for ; Wed, 23 Apr 2014 15:26:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.20.113 with SMTP id 104mr58081393qgi.71.1398291968427; Wed, 23 Apr 2014 15:26:08 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Wed, 23 Apr 2014 15:26:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Apr 2014 23:26:08 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11c12d1812165c04f7bd3859 X-Spam-Score: -0.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 (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1Wd5cL-0000hI-Ui Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 22:26:15 -0000 --001a11c12d1812165c04f7bd3859 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell wrote: > You can see me proposing this kind of thing in a number of places (e.g. > http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt "p2pool > only forces the subsidy today, but the same mechnism could instead > force transactions.. Interesting. You set the share-block size to 16kB and set the share POW to 1/64 of the main target. Each share-block would be allowed to append up to 16kB on the previous share-block. This would keep the bandwidth the same, but on average blocks would be only 512kB. e.g. to get you fast confirmation.", or > previously on BCT for the last couple years) but there are still > limits here: If you don't follow the fast-confirmation share chain > you cannot mine third party transactions because you'll be at risk of > mining a double spend that gets you orphaned, or building on a prior > block that other miners have decided is bad. This means that if the > latency or data rate requirements of the share chain are too large > relative to ordinary mining it may create some centralization > pressure. > This effect could be reduced by having "colours" for blocks and transactions. The block colour would be a loop based on block height. You could have 16 transaction "colours" based on the lowest 4 bits in the txId. A transaction is only valid if all inputs into the transaction are the correct colour for that block. This allows blocks to be created in advance. If you are processing colour 7 at the moment, you can have a colour 8 block ready. 16 colours is probably to many. It would only be necessary for things like 1 second block rates. The disadvantage is that wallets would have to make sure that they have coins for each of the 16 colours. If you spend the wrong colour, you add 16 block times of latency. > > That said, I think using a fast confirmation share-chain is much > better than decreasing block times and could be a very useful tool if > we believe that there are many applications which could be improved > with e.g. a 30 second or 1 minute interblock time. Mostly my thinking > has been that these retail applications really want sub-second > confirmation, which can't reasonably be provided in this manner so I > didn't mention it in this thread. > In a shop setting, you could set it up so that the person scans a QR-code to setup a channel with the shop. They can then scan all their stuff and by the time they have done that, the channel would be ready. If there was a queue, it could be done when the person enters the queue. In fact, there could be QR-codes at multiple locations. --001a11c12d1812165c04f7bd3859 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail.com>= wrote:
You can see me proposing this kind of thing in a number of places (e.= g.
http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.= txt "p2pool
only forces the subsidy today, but the same mechnism could instead
force transactions..

Interesting.=C2=A0 You= set the share-block size to 16kB and set the share POW to 1/64 of the main= target.

Each share-block would be allowed to append up t= o 16kB on the previous share-block.

This would keep the bandwidth the same, but on average block= s would be only 512kB.

e.g. to= get you fast confirmation.", or
previously on BCT for the last couple years) but there are still
limits here: =C2=A0If you don't follow the fast-confirmation share chai= n
you cannot mine third party transactions because you'll be at risk of mining a double spend that gets you orphaned, or building on a prior
block that other miners have decided is bad. =C2=A0This means that if the latency or data rate requirements of the share chain are too large
relative to ordinary mining it may create some centralization
pressure.

This effect = could be reduced by having "colours" for blocks and transactions.=

The block colour would be a loop based on block height.

You could h= ave 16 transaction "colours" based on the lowest 4 bits in the tx= Id.

A transaction is only valid if = all inputs into the transaction are the correct colour for that block.

This allows blocks to be created in ad= vance.=C2=A0 If you are processing colour 7 at the moment, you can have a c= olour 8 block ready.

16 colours is = probably to many.=C2=A0=C2=A0 It would only be necessary for things like 1 = second block rates.

The d= isadvantage is that wallets would have to make sure that they have coins fo= r each of the 16 colours.

If you spend the wrong colour, you add 16 = block times of latency.
=C2=A0

That said, I think using a fast confirmation share-chain is much
better than decreasing block times and could be a very useful tool if
we believe that there are many applications which could be improved
with e.g. a 30 second or 1 minute interblock time. =C2=A0Mostly my thinking=
has been that these retail applications really want sub-second
confirmation, which can't reasonably be provided in this manner so I didn't mention it in this thread.

I= n a shop setting, you could set it up so that the person scans a QR-code to= setup a channel with the shop.

They can then scan all th= eir stuff and by the time they have done that, the channel would be ready.<= br>
If there was a queue, it could be done when the person enter= s the queue.

In fact, there could be QR-codes at multiple= locations.
--001a11c12d1812165c04f7bd3859--