From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
Date: Sun, 7 Feb 2016 20:29:42 +0000 [thread overview]
Message-ID: <CAE-z3OWMyqHLAdd9+qqGN_oEXKb+MReGSANSQT9MxxiF6gHAhg@mail.gmail.com> (raw)
In-Reply-To: <56B7951A.2090800@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On Sun, Feb 7, 2016 at 7:03 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I would expect that custodians who fail to produce coins on both sides
> of a fork in response to depositor requests will find themselves in
> serious legal trouble.
>
If the exchange uses an UTXO from before the fork to pay their clients,
then they are guaranteed to count as paying on all forks. The exchange
doesn't need to specifically pay out for each fork.
As long as the exchange doesn't accidently double spend an output, even
change addresses are valid.
It is handling post-fork deposits where the problem can occur. If they
only receive coins on one fork, then that should cause the client to be
credited with funds on both forks.
The easiest thing would be to refuse to accept deposits for a while
before/after the fork happens.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
[-- Attachment #2: Type: text/html, Size: 2013 bytes --]
next prev parent reply other threads:[~2016-02-07 20:29 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 20:51 [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes Gavin Andresen
2016-02-05 22:36 ` Yifu Guo
2016-02-07 17:09 ` Gavin Andresen
2016-02-05 23:04 ` Btc Drak
2016-02-06 0:12 ` Luke Dashjr
2016-02-06 3:14 ` Jorge Timón
2016-02-06 15:37 ` Gavin Andresen
2016-02-06 17:01 ` Adam Back
2016-02-06 17:45 ` Gavin Andresen
2016-02-06 21:11 ` Peter Todd
2016-02-06 21:24 ` Peter Todd
2016-02-09 5:11 ` Samson Mow
2016-02-06 21:28 ` David Thomson
2016-02-07 18:49 ` Chris Priest
2016-02-06 17:09 ` Jorge Timón
2016-02-06 17:25 ` Tom Zander
2016-02-06 20:22 ` Chris Priest
2016-02-06 20:46 ` Luke Dashjr
2016-02-07 14:16 ` Gavin Andresen
2016-02-07 15:06 ` Alex Morcos
2016-02-07 16:54 ` Peter Todd
2016-02-07 15:19 ` Anthony Towns
2016-02-07 17:10 ` Jonathan Toomim
2016-02-07 17:24 ` jl2012
2016-02-07 17:56 ` Jonathan Toomim
2016-02-07 21:01 ` Luke Dashjr
2016-02-07 21:33 ` Steven Pine
2016-02-07 22:04 ` Corey Haddad
2016-02-07 22:25 ` Steven Pine
2016-02-06 20:36 ` Luke Dashjr
2016-02-06 22:22 ` Peter Todd
2016-02-07 5:21 ` Jannes Faber
2016-02-07 18:55 ` Jonathan Toomim
2016-02-07 19:03 ` Patrick Strateman
2016-02-07 19:19 ` Trevin Hofmann
2016-02-07 20:29 ` Tier Nolan [this message]
2016-02-09 13:59 ` Yifu Guo
2016-02-09 16:54 ` Gavin Andresen
2016-02-10 6:14 ` David Vorick
2016-02-10 6:36 ` Patrick Shirkey
2016-02-10 12:58 ` Tier Nolan
2016-02-07 11:37 ` Anthony Towns
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-z3OWMyqHLAdd9+qqGN_oEXKb+MReGSANSQT9MxxiF6gHAhg@mail.gmail.com \
--to=tier.nolan@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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