From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Date: Wed, 23 Apr 2014 23:26:08 +0100 [thread overview]
Message-ID: <CAE-z3OX3mC5bvBAXCoT3oECP6C=c=tLUD1QNVvdTcqLgQRyhcA@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgQQyY=BGcM21EJiMkwBH0G5J57ahYEiD=bQTuprLHrHPA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
On Wed, 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. 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.
[-- Attachment #2: Type: text/html, Size: 3878 bytes --]
next prev parent reply other threads:[~2014-04-23 22:26 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 7:55 Mike Hearn
2014-04-23 9:57 ` Andy Parkins
2014-04-23 11:07 ` Mike Hearn
2014-04-23 11:39 ` Andy Parkins
2014-04-23 11:45 ` Mike Hearn
2014-04-23 13:21 ` Andy Parkins
2014-04-23 13:31 ` Mike Hearn
2014-04-24 9:21 ` Andy Parkins
2014-04-23 12:43 ` Christophe Biocca
2014-04-23 12:51 ` Mike Hearn
2014-04-23 14:52 ` Justus Ranvier
2014-04-23 15:07 ` Mike Hearn
2014-04-23 17:19 ` Justus Ranvier
2014-04-23 17:47 ` Gavin Andresen
2014-04-23 17:49 ` Justus Ranvier
2014-04-23 17:57 ` Mike Hearn
2014-04-23 18:04 ` Justus Ranvier
2014-04-23 18:15 ` Peter Todd
2014-04-23 18:20 ` Justus Ranvier
2014-04-23 18:37 ` Mike Hearn
2014-04-23 18:49 ` Justus Ranvier
2014-04-23 19:01 ` Drak
2014-04-23 18:58 ` Tier Nolan
2014-04-23 15:04 ` Alex Mizrahi
2014-04-23 15:09 ` Mike Hearn
2014-04-23 15:38 ` Alex Mizrahi
2014-04-23 16:04 ` Christophe Biocca
2014-04-23 16:19 ` Chris Pacia
2014-04-23 16:21 ` Mike Hearn
2014-04-23 16:33 ` Kevin
2014-04-24 11:22 ` Jorge Timón
2014-04-24 11:43 ` Mike Hearn
2014-04-24 13:57 ` Jorge Timón
2014-04-24 14:28 ` Mike Hearn
2014-04-24 15:37 ` Jorge Timón
2014-04-24 17:07 ` Justus Ranvier
2014-04-25 4:31 ` Gareth Williams
2014-04-25 10:17 ` Mike Hearn
2014-04-25 13:19 ` Gareth Williams
2014-04-25 15:28 ` Mike Hearn
2014-04-26 12:15 ` Gareth Williams
2014-04-27 1:42 ` Christophe Biocca
2014-04-27 12:53 ` Gareth Williams
2014-04-27 14:31 ` Mike Hearn
2014-04-27 23:10 ` Gareth Williams
2014-04-28 21:41 ` Adam Back
2014-04-29 14:13 ` Mike Hearn
2014-04-29 14:21 ` Gregory Maxwell
2014-04-29 14:26 ` Mike Hearn
2014-04-30 13:12 ` Gareth Williams
2014-04-30 13:55 ` Mike Hearn
2014-04-30 14:31 ` Gareth Williams
2014-04-29 19:29 ` Justus Ranvier
2014-04-30 13:00 ` Gareth Williams
2014-04-30 17:06 ` Troy Benjegerdes
2014-04-30 17:13 ` Jameson Lopp
2014-04-30 14:08 ` Gareth Williams
2014-04-23 15:28 ` Peter Todd
2014-04-23 15:34 ` Kevin
2014-04-23 15:41 ` Pieter Wuille
2014-04-23 15:55 ` Peter Todd
2014-04-23 18:57 ` Gregory Maxwell
2014-04-23 19:19 ` Mike Hearn
2014-04-23 19:47 ` Gregory Maxwell
2014-04-23 19:59 ` Mike Hearn
2014-04-23 20:24 ` Gregory Maxwell
2014-04-23 20:37 ` Mike Hearn
2014-04-23 20:44 ` Adam Ritter
2014-04-23 20:51 ` Mike Hearn
2014-04-24 15:13 ` Sergio Lerner
2014-04-24 15:34 ` Mike Hearn
2014-04-23 20:53 ` Gregory Maxwell
2014-04-23 21:23 ` Tier Nolan
2014-04-23 21:39 ` Gregory Maxwell
2014-04-23 22:26 ` Tier Nolan [this message]
2014-04-24 0:55 ` Tom Harding
[not found] ` <CAKuKjyWDniyP503XSw8=tK9XQW-T58j+VD6ajXCxz=HihN93mQ@mail.gmail.com>
2014-04-24 14:52 ` [Bitcoin-development] Fwd: " Adam Ritter
2014-04-23 20:41 ` [Bitcoin-development] " Daniel Krawisz
2014-04-23 22:06 ` Alex Mizrahi
2014-04-24 7:58 ` Mike Hearn
2014-04-24 8:19 ` Gregory Maxwell
2014-04-24 8:39 ` Mike Hearn
2014-04-24 9:25 ` Gregory Maxwell
2014-04-24 9:56 ` Mike Hearn
2014-04-24 13:44 ` Peter Todd
2014-04-24 14:09 ` Mike Hearn
2014-04-24 14:47 ` Christophe Biocca
2014-04-24 15:03 ` Peter Todd
2014-04-24 16:05 ` Christophe Biocca
2014-04-24 16:14 ` Mike Hearn
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='CAE-z3OX3mC5bvBAXCoT3oECP6C=c=tLUD1QNVvdTcqLgQRyhcA@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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