http://pastebin.com/4BcycXUu

reddit discussion

Hearn posted the following message to the legal section of the members-only foundation forum: https://bitcoinfoundation.org/forum/index.php?/topic/505-coin-tracking/ If you're not a member, you don't have access. I obtained this with the help of a foundation member who asked to remain private.

He's promoted blacklists before, but Hearn is now a Bitcoin Foundation insider and as Chair of the Foundations Law & Policy committee he is pushing the Foundation to adopt policies approving the idea of blacklisting coins. I also find it darkly amusing that he's now decided to call the idea "redlists", perhaps he has learned a thing or two about PR in the past few months.

All Bitcoin investors need to make it loud and clear that attacking the decentralization and fungibility of our coins is unacceptable. We need to demand that Hearn disclose any and all involvement with the Coin Validation startup. We need to demand that the Foundation make a clear statement that they do not and will not support blacklists. We need to demand that the Foundation support and will continue to support technologies such as CoinJoin and CoinSwap to ensure all Bitcoin owners can transact without revealing private financial information.

Anything less is unacceptable. Remember that the value of your Bitcoins depends on you being able to spend them.

I would like to start a discussion and brainstorming session on the topic of coin tracking/tainting or as I will call it here, "redlisting". Specifically, what I mean is something like this:

Consider an output that is involved with some kind of crime, like a theft or extortion. A "redlist" is an automatically maintained list of outputs derived from that output, along with some description of why the coins are being tracked. When you receive funds that inherit the redlisting, your wallet client would highlight this in the user interface. Some basic information about why the coins are on the redlist would be presented. You can still spend or use these coins as normal, the highlight is only informational. To clear it, you can contact the operator of the list and say, hello, here I am, I am innocent and if anyone wants to follow up and talk to me, here's how. Then the outputs are unmarked from that point onwards. For instance, this process could be automated and also built into the wallet.

I have previously elaborated on such a scheme in more detail here, along with a description of how you can avoid the redlist operator learning anything about the list's users, like who is looking up an output or who found a match.

Lately I was thinking about this in the context of CryptoLocker, which seems like it has the potential to seriously damage Bitcoin's reputation. The drug war is one thing - the politics of that are very complex. Extortion is something else entirely. At the moment apparently most people are paying the ransom with Green Dot MoneyPak, but it seems likely that future iterations will only accept Bitcoin.

Specifically, threads like this one concern me a lot. Summary: a little old lady was trying to buy bitcoins via the Canada ATM because she got a CryptoLocker infection. She has no clue what Bitcoin is beyond the fact that she needed some and didn't know what to do.

The risk/reward ratio for this kind of ransomware seems wildly out of proportion - Tor+Bitcoin together mean it takes huge effort to find the perpetrators and the difficulty of creating such a virus is very low. Also, the amount of money being made can be estimated from the block chain, and it's quite large. So it seems likely that even if law enforcement is able to take down the current CryptoLocker operation, more will appear in its place.

I don't have any particular opinion on what we should talk about. I'm aware of the arguments for and against such a scheme. I'm interested in new insights or thoughts. You can review the bitcointalk thread on decentralised crime fighting to get a feel for what has already been said.

I think this is a topic on which the Foundation should eventually arrive at a coherent policy for. Of course I know that won't be easy.

-Mike Hearn

(also posted to the -dev email list)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It has been suggested that we leave the decision of what the blocksize to be
entirely up to miners. However this leaves a parameter that affects every
Bitcoin participant in the control of a small minority. Of course we can not
force miners to increase the blocksize if they choose to decrease it, because
the contents of the blocks they make are their decision and their decision
only. However proposals to leave the maximum size unlimited to allow miners to
force us to accept arbitrarily large blocks even if the will of the majority of
Bitcoin participants is that they wish to remain able to validate the
blockchain.

What we need is a way to balance this asymetrical power relationship.

Proof-of-stake voting gives us a way of achieving that balance. Essentially for
a miner to prove that the majority will of the poeple is to accept a larger
blocksize they must prove that the majority has in fact voted for that
increase. The upper limit on the blocksize is then determined by the median of
all votes, where each txout in the UTXO set is one vote, weighted by txout
value. A txout without a corresponding vote is considered to be a vote for the
status quo. To allow the voting process to continue even if coins are "lost"
votes, including default votes, are weighted inversely according to their age
in years after 1 year. IE a vote with weight 1BTC that is 1.5 years old will be
recorded the same as a <1 year old vote weighted as 0.67BTC, and a 1 day old
and 6 months old UTXO are treated equivalently. The 1 year minimum is simply to
make voting required no more than once per year. (of course, a real
implementation should do all of these figures by block height, IE after 52,560
blocks instead of after 1 year)

A vote will consist of a txout with a scriptPubKey of the following form:

    OP_RETURN magic vote_id txid vout vote scriptSig

Where scriptSig is a valid signature for a transaction with nLockTime
500,000,000-1 spending txid:vout to scriptPubKey:

    OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

vote_id is the ID of the specific vote being made, and magic is included to
allow UTXO proof implementations a as yet unspecified way of identifying votes
and including the weighted median as part of the UTXO tree sums. (it also
allows SPV clients to verify the vote if the UTXO set is a Patricia tree of
scriptPubKeys) vote is just the numerical vote itself. The vote must compute
the median, rather than the mean, so as to not allow someone to skew the vote
by simply setting their value extremely high. Someone who still remembers their
statistics classes should chime in on the right way to compute a median in a
merkle-sum-tree.

The slightly unusual construction of votes makes implementation by wallet
software as simple as possible within existing code-paths. Votes could still be
constructed even in wallets lacking specific voting capability provided the
wallet software does have the ability to set nLockTime.

Of course in the future the voting mechanism can be used for additional votes
with an additional vote_id. For instance the Bitcoin community could vote to
increase the inflation subsidy, another example of a situation where the wishes
of miners may conflict with the wishes of the broader community.

Users may of course actually create these specially encoded txouts themselves
and get them into the blockchain.  However doing so is not needed as a given
vote is only required to actually be in the chain by a miner wishing to
increase the blocksize. Thus we should extend the P2P protocol with a mechanism
by which votes can be broadcast independently of transactions. To prevent DoS
attacks only votes with known vote_id's will be accepted, and only for
txid:vout's already in the blockchain, and a record of txouts for whom votes
have already broadcast will be kept. (this record need not be authoritative as
its purpose is only to prevent DoS attacks) Miners wishing to increase the
blocksize can record these votes and include them in the blocks they mine as
required. To reduce the cost of including votes in blocks 5% of every block
should be assigned to voting only. (this can be implemented by a soft-fork)

For any given block actual limit in effect is then the rolling median of the
blocks in the last year. At the beginning of every year the value considered to
be the status quo resets to the mean of the limit at the beginning and end of
the interval.  (again, by "year" we really mean 52,560 blocks) The rolling
median and periodic reset process ensures that the limit changes gradually and
is not influenced by temporary events such as hacks to large exchanges or
malicious wallet software.  The rolling median also ensures that for a miner
the act of including a vote is never wasted due to the txout later being spent.

Implementing the voting system can happen prior to an actual hard-fork allowing
for an increase and can be an important part of determining if the hard-fork is
required at all.

Coercion and vote buying is of course possible in this system. A miner could
say that they will only accept transactions accompanied by a vote for a given
limit. However in a decentralized system completely preventing vote buying is
of course impossble, and the design of Bitcoin itself has a fundemental
assumption that a majority of miners will behave in a specific kind of "honest"
way.

A voting process ensures that any increase to the blocksize genuinely
represents the desires of the Bitcoin community, and the process described
above ensures that any changes happen at a rate that gives all participants
time to react. The process also gives a mechanism for the community to vote to
decrease the limit if it turns out that the new one was in fact too high. (note
how the way the status quo is set ensures the default action is for the limit
to gradually decrease even if everyone stops voting)

As many of you know I have been quite vocal that the 1MB limit should stay. But
I would be happy to support the outcome of a vote done properly, whatever that
outcome may be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRtVFBAAoJEEWCsU4mNhiP6EAIAMjq4UgXxmEjOgHWf0KcmwmH
Ra/I3oY7krvg/lu1YCa+ACMBdoca9WODySUIe7R3niphKXEnknHGUIf8tm/Vrq4H
gPF4cgYEr18EYTVtvT9J1pZUB4f5dxkXXNpcQ60juaz9KervFQMOGnpr6Fyxi3dS
ghObNYcr3D2v1fjx56sp7BCNn0XHxTb1ZLUJB0BZhDKlamfgcxruKMbpsZmACJUj
gTNLNweaAomBIH++j7cnXeB0jZc/1ilv8qLA/f3TGb43FDkAQcvvSjGijI+OJOm6
Fh/WRBav1BJiV6PKs9xuHXsaxZ/T7Fb8Wg8EynSi0mSj47QXdKZgeZCi3XlSyxM=
=aKBD
-----END PGP SIGNATURE-----

(reposting the bitcoin-development email for visibility)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is therefore vulnerable to DoS attack, so hopefully that will
continue to allow adoption to proceed gradually. We can-not recommend mining on
mainnet with it. It does not include an "undo" RPC command or an adjust fees,
and Peter says he has not implemented one yet.  Patches are welcome.

Specifically there were requests from vulnerable parties, which interestingly
included a site that knew they had bugs related to replacement but not
financial vulnerabilities, to put up a server on testnet to check wallet code.
The vulnerable requested to remain undisclosed. An additional consideration was
the upcoming anti-dust rules which are yet another example of why zero-conf is
so much more dangerous to accept than single-conf. Two of the people contacting
us brought up that issue in fact.

The code is on github:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee

and a replace-by-fee server operating on testnet is available at
testnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use the
raw transaction API and manually create the replacement transaction. Do note
that your wallet will retain the existing one and no mechanism yet exists to
delete the old transaction from your wallet. Again, a certain amount of
"cludgyness" to this is intentional to discourage premature non-testing use.


Regarding the reward, I've decided Peter will collect the full amount even
though the work is not %100 complete (the mempool aspect) due to his concern
about staging an implementation properly, working with vulnerable sites, and
overall genuine interest in the actual issues at hand rather than the reward.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz
6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu
41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDq
J/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUuj
Fgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4A
GtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug=
=M1mj
-----END PGP SIGNATURE-----

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

https://github.com/bitcoin/bitcoin/pull/2577

Many Bitcoin users are going to be affected and see their funds blocked. For instance ASICMiner share payments, BitHits faucet payments, anyone depending on microtransactions. If you depend on small payments you need to change your business model now or find yourself shutdown overnight.

Gavin: It's sad that you aren't willing to speak about this publicly on the forums, rather than hiding away all the debate on GitHub away from the general public.

edit: To be clear, I like the patch: https://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17138223

What I don't like is when I realized not once had Gavin or anyone else in the development team made a public statement that this change was coming down the line. If I hadn't made this post, for all I know it would have been hidden away in the next Bitcoin-QT with no warning at all, right when we all have to upgrade before May 15th.

Why isn't think on your blog or someone else so people have time to change the way their businesses operate? Why the secrecy?

I've opened a pull request to add the protection and promotion of decentralization to the bylaws of the Bitcoin Foundation.

https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/pull/4

Right now the bylaws don't really say what the Foundation's purpose is. Just some vague statement about promotion, protection, and standardization of Bitcoin and related technologies. What exactly constitutes "protection" is left completely undefined. For all we know it includes changing what Bitcoin is to make it more palatable to authorities.

The Foundation needs to make it clear what it's vision of Bitcoin actually is. Is it some payments system useful for businesses? Is it meant to make investors rich? Or is it meant to be a democratic, decentralized currency?

The word 'decentralized' doesn't even appear in the Foundation bylaws at all. Nor does anonymity or privacy.

Of course, the Foundation isn't Bitcoin. But they do useful work and I myself have supported them financially in the past. However I do not feel that I can in good faith support them in the future until they are clear as to what exactly is their vision of what is Bitcoin, and if decentralization and privacy is even a part of that vision.

Right now we just don't know.

I have been around Bitcoin for awhile now and have been an investor for almost as long. I really believe that Bitcoin has the potential to be the worlds decentralized, inflationproof store of value, really electronic gold, and it's only been in the past few months that I've been reading Peter Todd's and Gregory Maxwell's writings about the bitcoin blocksize and how important the 1MB limit is to keeping Bitcoin decentralized.

Peter has a new project to create a video/website explaining the limit and how important it is to Bitcoin: https://bitcointalk.org/index.php?topic=189792 I just donated 1BTC to it myself.

Bitcoin as a payment system just doesn't drive up the price in a long-term stable way. It's just basic supply and demand and as using Bitcoin as a payment system becomes more efficient and the velocity of money goes up, the overall demand for Bitcoins goes down. At the same time you're investment is subject to the risk of alternatives that provide the same low-fees and no-refunds policies that make Bitcoin useful for payments. It really worries me to see the foundation mainly funded by companies that are invested in payments rather than Bitcoin as the store of value that it could be.

I don't think the people in Cyprus, Russia and China care about payments. I think they care about anonymity and the inability of anyone to take your coins from you. We can't let that be risked for the sake of SatoshiDice.

This sig was very clever:

AKA Peter Todd
1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
PGP: 37EC 7D7B 0A21 7CDB 4B4E  007E 7FAB 1142 67E4 FA04

It timestamps a PGP key fingerprint in the blockchain with a transaction an address generated directly from that fingerprint. (Note the hex URL) Thus even without the web of trust I can be pretty sure a year from now that I am looking at the correct key rather than an imposter.

What would it take to do this on a widespread scale? The PGP strong-set is a bit under fifty thousand keys right now. If transactions are cheap, perhaps a penny each, that would be just five hundred dollars and would greatly strengthen all those keys for the future. All the keys on the key servers is probably just a few million.

If anyone wants to make the strong set secure I will pay the transaction fees and a tip for your time. Proposals?