Gregory Maxwell made an excellent post on this subject, emphasis mine:

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.

-Mike Hearn

I'd like the administrators of this bounty to make clear some conditions for a large portion of the reward to be given:

• Testing - It has been rumored that the recent 200BTC fee transaction was the result of a failed CoinJoin transaction. Regardless of whether or not that is true, unittests and good coding practices should be taken into account.
• # of users - Take into account the # of potential users. Solutions applicable for a larger % of the total Bitcoin userbase are much more important than solutions not so widely applicable. Solutions that can be used 'by default' are far more valuable than ones that can-not.
  
• Licensing - Part of being widely applicable is the license of the software. I am in RMS's camp here, and while normally it makes sense to use restrictive open-source licenses in a tit-for-tat scenario, like him I too believe that sometimes getting the idea as widely used as possible is the right approach. Note that RMS has specifically said this in relation to Bitcoin's MIT license. Implementations should use licenses no more restrictive than LGPL.
  

As the largest individual contributor to date I hope my words are taken seriously.

Yes, I am writing this in response to Amir's proof-of-concept, which is nice to see happen quickly for people to play with, but to see it reported in Bitcoin Magazine already as "and today, two Bitcoin developers in Spain have come up with a solution." very much bothers me given how far it is from a complete solution.

For one thing, the code has rather frightening constructs such as:

call("sx rawscript [ %s ] [ %s ] | sx set-input txfile.tx %s > signed-tx" % (signature, pubkey, input_index))

I would not in the least bit be surprised if there is either a shell exploit already present, or there will be one in the future. In addition there is no license for the code, and it depends on sx/libbitcoin with are AGPL licensed.

tl;dr: I would be happy to see Amir and co receive a token BTC for their efforts, but they have to put a lot more work in for what they have done to be worth more than that.

Edit: donating more

I may be jumping the gun a bit, but please accept this 10.11BTC donation to the fund:


-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQIOAwAAAAAAAAAAEAgAhYb+uVMQsS/LBxtWH3PKcfQkpBhbygfrRLtaZn4DSPGP
F12rmQQ8QRJOiRyKgrXrwXWoLZ4cFA9q2VabhyiYLWo/NO+pdP+h/XnHteTmjvTI
rRwZjMtXntGZO2Awh+BpsKlUyfnDpCuPbkZGT82/iubUWhTrbQAPseEISVArP9Jd
SvPVnw2cHQnvBu9aU6+qzf7rmYox2dMYPHkAtRLtAYO5WU087dhGWoNW0S7E6pNG
P8NkYYg18YJA7wHZ9raBf6QzhhEJY4ppuIIe6P60CzxsU+acswPA3yFKjzPXaMQv
ZeglXsOC/jWX36s/f7Q03ICPg2wEguJiMrKPDew9fwf/eX+or4F1QLJWX7e2bPbS
hMsI+H/EjV9iuNoRmYmWQq+Q+aP6RZC6SwESXEgp0lqr3poLO0za7mYuxiiZg2IQ
1255u2yVz0ikdGv1VKr2tyEZLitARID3YVetEWdTIm/rlHsKV7stF6zh+fnVIHjx
jkmaKa4G8dGGOhDt2xLsgfB6oJ9iuDJHSDL9nXU3aanTPc7E8NFhUHrxBW+CWu6E
wo7xlnfjYrSYFTjrhVqm0ywbWmpyTdhb54w7AroOjeTU7axgcbNV4b59v0H8HSx2
EGlDnSf4wKWPX28c9r/aXevd5Jt2GQtwI48noqKNC4ryPVgZF65FpaRy7Z0E9s21
CIUBDAMAAAAAAAAAAAEH/0QxCBCEp8x+QwA1WwvyD4/f4OW8LAjKO2idR9NNJFx0
yLK0ohtX5nGryZujvAwvZmG1Haanj9QFQ26Xxpe4NINGee3EZ/kBMIxDWQ7vqXmx
yvU+g6W8lhwWO4Fs9mX5yrt/KnYL2AS5e4A3ZKXiJzLvd+fQ26NuuO9UTeHvB4fv
DaivRxV+Jytfym875cob+q4BvjklqjW4QSKMLMZbHXUgYlqmEWbVdIqOMoa/11nA
c9vYWzMBv4+dzX1QNILtAjH57zac2axowKDanZ0zCmp0WyZu3ZzDRP3/SIIilCKr
TrKxTeRzgJssOacxahH9qSFxYlWbtZ61mZJmU8Ny7HaFAQwDAAAAAAAAAAABB/9D
krpjhcyVrDTq/6b8QiCxznCiv8GvMLQEs4amVStGXYY8YnwuTqcOpzrMno0/FQp/
atkMc8mR1LoeWd182YRvnRRDqBM3Iz8OsEPOM2Pnjgi/ZTrKkncWMOiZALjH2vLT
JKCJa62ou08cDL6Y+sX9SHQOpxG3kG1/QcKaaqwpbQLLm6lz4TxF1+c/Mjd9Zukq
3qq9h2v7gwbc6KJXsq3ZbXp5prNgAhtoJPRIv+kcxnfEwO0hpGnyoJ1xb16YsqMN
L6JmmHKJhi60B6t4S8TWvth7piVfce1d6izDpXQJ2gmkNS/mah3rw/jpeCdHgeQd
PnqaSkj5Nmqa98rbYQyo0ukBYW9cHSZONbFqT994oSU/7C+8GVFPXet+gxbja9nB
kaWwi1PL7ngSSrYbchzrREmLxNY3RALVwcjWyPrc7Dax+G+vfVw+dANzxQtt0a22
J6hFVBAp70XvNM9YCg1CkAIqnyd+Y8bYmgAcAkNOovg2KZh0wWmziAEP/FizNbZm
xpWd4TXzTKNae3usoJxjBGUS6DAk26fZFkvczqEDJBW3GCPHYcupIa9k9FECnIaF
Wp/YodreY3bzFWidJpFZtpvt4qLz/PovxhZoR/9nqBjwsCJSEXtx7VcuPjKKWCRx
7miDE/xzKS8QIKV8/BZjcNf0S6H/BwxnGyzLTVSpukPvqy8B/RxUO+nf4RFSNpNT
jp+0tlILpncwzTDL2h6FF/jtj+nl4cTT23ZazbkuYAlxnwMxU+GU6jtQZLHAoYdo
n9TjMNDZZCRN5spMWu1UWnKqQ1Gc43q0vUJ+s5KWj2T3lOoYoSsNYrAQmPoilsLH
3Lh0Lg4sPVoG1DwwKXOVrkJF34utSlCFl63h/PMFXmjRgcueb0Ta6POU4njGg8VY
sEKc0bux7+lK0bMgoQA3O/quxHsK0Q3uQVWmNtTjqU2uf/sE3mz5twTGU8bDOWYu
88PuGBANtQHkNR1Cz1yHnPug5tI8NXYsC3PNKnu9DmI9y4TBK6qFSfJm8cZVbfLS
AcD7vvQgizaMTNi8FW4/NfKi0tNLE8foZgV1m6pXgYr4pzfWhWdcJUZ7ClV41Vzl
RDayvveBOWy/w68eUc8/5nWmH6+phmwtpjFWuht/OIGY1Oo91LoO0h+CgMKf5kur
zCBa72DTZfVpaDzwaRcr8tcP60u77PYrL8NMw6LP9q7760bbij+DJ274tWlmJnsM
9q/ZhVXm7bW5m1gXIGO7Hl4Dce9S3ImxxzCogcwP0VaZP4IZPNCmmK8xkmIiAKDV
Rr8mKh00KtaP0tby06IOuRr5bo2XbMo0knEwsdVHyM/yocAfPMbfPlJlao5ZI/XA
xV5db7pETa08sjKoYGHyjvJnclQ9P0yFy8jK/b8LoFAej/bVGQwdckIsBIEUg28F
C1tOskPkd7B4fiL4tGqfEkI7msvGYgH366kI63osglOcaYTj4BzvufkqSO4LwgLK
yzZlmyVfx+PaJzoL1F+IGUAmD9E4Fz5dporFHGW2elAtIh8MEywyZyPWvr1kJ5Q8
iEe3CHLM0X834PwLQ7snKzuoCulRvQnuiwfqVqASTwwjR05XpzhcalWAkhSPgRG/
rj1GXIngmSEO/hiFSOE=
=AaHO
-----END PGP MESSAGE-----

What I most like about this concept is its simple engineering pragmatism. You know, ZeroCoin solves exactly one problem really well, but it solves it so well because they pushed the envelope so far in one particular direction. From an academic point of view it makes for great papers and clever theory, but the history of cryptography is littered with empty and disused ivory towers, and in any case often those towers lack railings.

I have to wonder how many of the people pushing ZeroCoin so hard even recognize that it needs a mix net or a standard way of getting your transactions to those you are paying to be useful?

AnonyMint: You come so close to being pragmatic in how you recognize the need for mixers for communication. But then you miss so badly, like it or not, normal users will make mistakes that reveal their identity, and CoinJoin can help make those mistakes less devastating. In any case it is usually not the boogeyman of three-letter-agencies who the users of CoinJoin would be trying to protect themselves from, but individuals and businesses who simply want to use Bitcoin with the same level of financial privacy they enjoy in with the convention banking system.

Look at the above. I am happy to have the world know I am giving 5BTC to this effort, and I am happy for Gregory Maxwell to know that it is me where the money is coming from. But why should I give the whole world insight into my finances? With CoinJoin I won't have to use something as convoluted as encrypting an access key, and the proposals above share a common thread of being such that all the actual complexity can be hidden away in software with a sufficiently sophisticated implementation.

Alp: This work looks really interesting. I'm also excited how Peter figured out how to use the nonce-based way of implementing it to protect savings accounts in wallets, really nice work!

Between these two uses, and existing uses for multiple CHECK(MULTI)SIG's in a scriptPubKey, I think it makes sense to create a whitelist for opcodes least likely to cause us problems and allow them in serialized scripts for use with P2SH. That removes the UTXO bloat problem of allowing anything, and limits the risk from opcodes we haven't implemented correctly. (I left out arithmetic from my initial whitelist, just boolean AND and OR for now) I posted my full proposal to the bitcoin-development email list: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02606.html

You should post your thoughts to the list, especially to figure out if the restriction to just boolean opcodes is ok for the first trials. I think it is, we can always extend it later, but if you have a really good argument for arithmetic make your case. Just remember that there have been some serious bugs found related to arithmetic before, so IMO playing it safe initially is a good idea.

Seems to me your advice for someone deciding if it's worth installing security screens on their windows in a high-crime area is "Why bother? All the thieves have to do is rent an excavator."

The security of Bitcoin itself is a matter of cost-vs-reward, the 51% attack, so we should ensure the cheapest way to attack Bitcoin remains via the extremely expensive 51% attack.


I see you would have rather Peter done nothing and let an actual attack on mainnet continue.

I'm glad we didn't put you in charge of the defense of the island of Britain back in WWII.


So are you going to report the issue so someone can fix it? Or are you just making up bullshit?


I remember from your tx-replacement debacle your "solution" was to rate-limit replacements, thereby making the replacement feature useless until the attacker gave up. Meanwhile you aren't willing to accept taking fees into account to allow legit users to get their replacements prioritized, and in general you even advocate that we do away with fees in general.

You also didn't answer Peter's question about what limited resource you would like to see SPV clients spend so that a DoS-ing attacker can be distinguished from legit users.

Funny that, I seem to remember Pieter Wuille, Matt Corallo and others arguing with Peter on IRC about P2SH, note how Peter's arguing against:

http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/03#l7531211

P2SH-only is also on the Bitcoin feature wishlist on the wiki, and Gregory Maxwell argued for it was well when he proposed P2SH^2. It'd probably just take some more child-porn related materials in the blockchain to get OP_CHECKMULTISIG disabled, remember that with it you can easily both insert data and make the txout spendable at the same time so that even if you decide you will blacklist txouts in response you are forced to blacklist spendable txouts and thus take peoples money. That is a much harder problem politically. Great fun could be had by someone creating time-locked announce-commit sacrifices spending those txouts in the future with large fees or to particular people. Do you really want to have a process by which we change the rules for how individual transactions can be spent by a central committee based on evidence that is illegal to examine, and thus illegal for the community at large to admit to auditing? Warning that P2SH and pay-to-script-hash (both are compatible with gmaxwells proposal) may one day be the only legal transaction types is a very reasonable thing to say.

It's what you write is what we need to take with a pinch of salt.


Unless you make stub transactions you will find your users getting their funds locked up because of merchants failing to get the transactions mined for whatever reason. For many merchants there isn't a strong incentive to get a transaction confirmed quickly because they either don't actually incur a cost immediately (shipping) or because anti-double-spend measures are working properly. At least with P2SH if miners do child-pays-for-parent the client can get the transaction mined that way regardless of what crazy scripts the merchant wants to use for txouts in their wallets.


No, as Peter pointed out it is 1 byte more efficient than the pay-to-script-hash method used currently, a method that protects Bitcoin from an ECDSA compromise. The 15% comes from the theoretical minimum transaction size, which creates dangerous risks for Bitcoin as a whole.

Besides, since when did you care about blockchain bloat?

The Bitcoin developers are well aware of this non-issue: http://sourceforge.net/mailarchive/forum.php?thread_name=CAJHLa0MVrQN6hyuAsYNRJ2CV6fsPnAbRDSUQH%2Bn6jfKdMiFaLQ%40mail.gmail.com&forum_name=bitcoin-development Every change to Bitcoin that blocks some transactions from propagating for any reason, such as them being harmful to the network, has this effect.

Zero-conf transactions have never been safe. For instance as pointed out on irc by Peter Todd because Elgius has 3.17% of the hashing power and blocks Satoshidice transactions you can profitably double-spend Satoshidice in principle, earning the different between the 3.17% hashing power and the Satoshidice 1.9% house edge each time. (actually doing so profitably is difficult however due to the risk of ruin among other things) You can get an even better edge by identifying all the miners blocking Satoshidice transactions and submitting to all them simultaneously, and you can further improve upon that edge by identifying miners blocking other addresses as well such as the "correct horse battery staple" address that was used to spam the network.

Never mind that because Bitcoin does not implement double-spend detection the vast majority of clients would never know if you simply broadcast two conflicting transactions at once. In that case there is a 50:50 chance of the transaction to the merchant being mined. Blockchain.info even created a easy to use tool to automate doing this: https://blockchain.info/create-double-spend (although it's hard to click both "send" buttons fast enough for it to work, it works better if you submit one transaction on your local bitcoin node)

However we can make zero-confirmation transactions safe without complex trusted identity systems, ironically by making it easier to double-spend. If we implement replace-by-fee nodes will always forward the transaction with the highest overall fee (including parents) even if it would double-spend a previous transaction. At first glance this appears to make double-spending trivial and zero-confirmation transactions useless, but in fact it enables a powerful counter-measure to an attempted double-spend: the merchant who was ripped off creates a subsequent transaction sending 100% of the funds to mining fees. All replace-by-fee miners will mine that transaction, rather than the one sending the funds back to the fraudster, and there is nothing the fraudster can do about it other than hope they get lucky and some one mines their double-spend before they hear about the counter spend. The transaction can also be constructed such that the payee pays slightly more in advance, with the merchant refunding the extra amount once the transaction confirms, to ensure that a double-spend will result in a net loss for the fraudster.

Peter Todd is working on writing better memory pool code that will enable this technology for safe zero-confirmation transactions, although he has told me it won't be ready for awhile due to the careful testing required, and it only makes zero-confirmation transactions safer in proportional to the miners who adopt replace-by-fee. (currently about 0.25% by my ad-hoc measurements) That said if a reasonably large fraction support it, simply asking for a risk deposit as mentioned above or some other insurance method is an adequate approach to deal with the % of miners who will ignore the counter-transaction.

It remains an open question as to whether or not the core developers accept the changes required for safe zero-confirmation transactions, Gregory Maxwell's comments on the idea are worth reading: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02226.html

I need to get better at not touching that "show/hide" option... But on IRC yesterday most of the developers put piotr_n on ignore for being an idiot who wouldn't listen to people showing why his idea was stupid and wasting everyones' time instead: http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/06/28#l7875194 gmaxwell has the patience of a saint. (or a C++ developer on a slow machine)

Remind me to use the self-moderated threads option more often.


EDIT: I'll also point out how this "one-line-change" DoS attack was something that at least one of the Bitcoin developers knew about but didn't even realize it was an issue: http://sourceforge.net/mailarchive/message.php?msg_id=31074593 Hopefully the other developers were just keeping their mouth shut and immediately understood how serious that issue was, but obviously it took a bit of insight on Peter's part to realize that the problem existed.

Heck, here's a Bitcoin for your efforts. Thank you!


-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.11 (GNU/Linux)

hQEMA8xUMVQPvvGFAQf/frPPA2CHPDlMz9R28K05T3/wVmGhQ54v803OH8+SImg+
RQ8dGqh5H8Tgar8cuKE8jhikr5bg6NBf369F4h1L4Ir1lnplY2wDJj4tRr97Ea8b
4ADm91Fr0CWT03pa9XIp4LsgIC1oc3l2PUXxCQ/icVUnZk0jhSyp4ZnR0MYsRGqi
GuoVGHP765Xai7I56nLIO4E6LFqnvj5zIGgKYjc4o9ujmOs73gph5eGWEdna3rOG
GKkHrajshLviRgKGa99uG2RxtFltE8BcFkW1D7xweV8TLLH6jAGhIG2XrPol+bLc
RoQQZr3zR1w0ORdXL6GkIerxw4MNBI5hKRm4w93WRIUBDAO4Pc5vOCVNqAEIALeU
FJZZ8BUtgiQ4mMIUrEFXOD5h1BqqIsavUosOR3mVJNWtlnHuasYGn2LvFqJw1SzC
7uB1bGk7xyVNAOGECFDu6r5T9Diur6pr+CSxbRjh19dqNi+noKiD3V1z6yk6USf/
rqlfm13k7Tat6T4b1Kp/4JC8ofarL3ogyCzF3MXFbdnCBuqndklqDakb66iQv4SE
BI7rwWwwtaeI83uUBTQpJkH0wL1boHfjKtpuh4jOETOQ8zKJxWOFm4BJl6TzHmYf
/hnm5Wc7JIsV1GMqQYwNreJ+6RRBpPV5mayomzF9n01yOwV/rKY7bDBAS0LU5LEV
DcSuqJ6FRbihiFibS0HSwN8BhY0LpbmFCGH9NrHYHQW7WQ8tZVbMGvVSEoOwUdEZ
JUV7Uj3nLIGnmZ9vfePcu7zxCwUbrMk3eX1huaBbeCwdv/zkHQtzMTTySOAhbgxx
LcCZuUTUXDdO8oFCJD/3PUlBJgxniVkSGcsbMUo2ev+Lr541iWGmd+J6FlZvgwsz
bE0PkOtIyttYvMBHfqUJ9DN7xLLKu/gJnzcs0UrLauXrbFvV3NsBL6LcuZ62zp4n
Sj+iy+9LOnr2tOjv7uVyujut4moCHteFcD7VIBjr0Lxuzxf/scdPSe73Y9Rgs4yX
n8e+RjgOV6k4hjMKeyQRSutHuUHKY0OTtdEW7dbfnUpFR+n8dDqnS0uueMrCNakM
b0xxdHEZSticRzuv7mY8FVJ2AIMFaIlrGInorYbUBtqiAnkcfCD+LI0Vqz7fX8RP
8s7EK584hzzKvFgIYUQ5h4sNgo19ryvnNoeEJh73z3Bho5e6+nVdyW0M8U8hreio
xFHANgf+s46k2vmj9cVl1sH8tW5NOxTfQa+POmRAnIunLCfR9IDJUWCfiJBeYXJI
=6qYH
-----END PGP MESSAGE-----

Thansk! Waiting however long you feel is required is fine by me.

The guy who last week saved the Bitcoin network from an extremely serious DoS attack that could have easily taken down a large fraction of the network  goes to the trouble of writing an intelligent and detailed response and you obviously don't even read it? Then you go off on conspiracy crap? Troll.

/ignore


Peter: write up what exactly you did there, I'd love to hear the full story. I didn't realize you had written that patch as the main network was being attacked! I guess it would have had the effect of inoculating the whole network because the truncated messages would propagate faster than the non-truncated ones, clever!

Rejecting transactions that are not accompanied by votes would be logisticly difficult. When you send a transaction generally only one of the outputs will be owned by you, often none of the outputs at all, so unless miners are willing to make it impossible for you to send funds to someone who is off-line or simply does not wish to vote they will be unable to coerce votes in that way. We can and should further strengthen this protection by having all nodes only relay votes for outputs of confirmed transactions, never unconfirmed ones.

There was no plan. All we have is some random comments from Satoshi suggesting a possibility.

Note how the proposal is careful to note that not voting is not a vote for a 1MB limit, but a vote for the status quo. In the future that status quo will probably not be 1MB, so your default vote will be for a different, probably higher, number.

Adding the voting feature is simple and easy. There just aren't that many clients out there so I really do not see the issue there.


Unfortunately that just isn't possible because miners fundamentally control what votes get into the blockchain at all. What you are proposing allows miners who wish to raise the blocksize to rig the vote by ignoring transactions voting against an increase, and it just takes a 50% majority of miners to do that. Not exactly a compelling majority of Bitcoin users is it?

Anyway, the point of my proposal is we know that miners can effectively reduce the blocksize by just not creating large blocks and not building upon the work of other miners, but we can coerce them into creating larger blocks by offering them fees. But what we can't do is limit how large blocks can become, which is the limiting factor for how easy it is for someone to become a true miner themselves. (not just someone working on behalf of a miner) Controlling the upper limit to something the whole community can agree on is what is important because we all benefit from a Bitcoin where the resources required to operate a full node are acceptable, for some value of acceptable.


"Very few"?

-http://garzikrants.blogspot.de/2013_02_01_archive.html (emphasis his, not mine)

That's Jeff Garzik, a highly respected core developer. Gregory Maxwell and IIRC Pieter Wuille shared those same concerns on IRC. Gavin is the odd man out in the core-dev team to think that leaving the decision up to miners is OK.

The thing is we already have one voting mechanism, mining. But that is a mechanism where the right to vote is dependent on your access to highly specialized hardware and in practice has been held in the hands of a very few in Bitcoin's history due to the natural incentives for miners to mine at large pools.

By adding proof-of-stake voting you counter-balance that vote with one where access is determined by a resource that all Bitcoin users have, Bitcoins themselves. Obviously we can't force miners to make larger blocks, but we can make it clear what maximum size we will accept, so the two voting processes go hand-in-hand.

As you say, it's a dispute resolution mechanism.

Voting is a simple, automatic process. Your wallet would have a pop-up when you configure it asking what you want your vote to be and giving a bit of education on what the option actually means. After that the process can happen entirely automatically. Submitting a vote doesn't cost you anything in time or money and unlike leaving the decision 100% up to miners it ensures that entities like the Winklevoss twins with the connections required to get access to mining hardware on a level playing field, BTC to BTC, as you are. (Mike Hearn for example has said he expects for mining hardware to be highly regulated in the future)

Frankly what are you guys worried about? Losing? If Bitcoin users really want a large blocksize they'll vote, and it'll be easy to convince them to vote if they see fees going up and want fees to be lower. Voting is an excellent answer to those suggesting that politically powerful members of the community are pulling strings by taking the issue out of their hands entirely.

Gavin Andresen has said repeatedly that he doesn't want to be "the guy" setting the blocksize. Others, including myself, have said repeatedly we don't want the tiny set of large pool owners setting the blocksize. With voting both parties can be made happy.

(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-----

Cooperative unmixing is only really voluntary if the people participating in the unmixing are anonymous. Otherwise you have known and non-anonymous individuals facing the charge of obstructing a police investigation. Though I will grant that it has the possibility of delaying investigations through multiple jurisdictions, not unlike the Tor model. Tor however is always pretty clear that participants are expected to not maintain logs, for a reason. So the question is why do we want to move away from that model? You have to ask what is so different about finance verses information that we suddenly give up our resolve to allow people freedom.

No-one talks about co-operative unmasking for Tor operators "just in case" we want to trace a crime committed over Tor that the community can agree on.

Ha, and I hear you called Peter either "The Devil's Advocate" or "The Antichrist" at the conference. (my source wasn't quite sure)

As I was saying, I think all this talk is a bit pointless and distracting from real work that could be done, so I'll do what I can to end this thread in the usual internet tradition.

Heil Hiter!

The wording "using Bitcoin for products and services" is very specific. As Peter pointed out earlier the fact that transactions currency cost $12 each shows very clearly that the market does not think Bitcoin as a payment service is valuable now, but instead either thinks it will be in the future, and/or sees Bitcoin as valuable as a pure investment.

"Actually writing code" is misleading. The core developers other than Gavin have a consensus that while the blocksize may be raised in the future decentralization is important and raising the blocksize must be balanced against that concern. Unfortunately for the payment side of Bitcoin that consensus also is that off-chain transactions will be required for low-value payments and you can see that consensus in action by how the developers decided to block microtransactions from Bitcoin on the basis that they weren't valuable enough for the resources they use. The question is how low is too low? No-one knows what that answer will be because as long as payments happen on a decentralized consensus system the cost of a transaction depends on how popular Bitcoin becomes. Put another way, O(n^2) scaling is a bitch.

A more interesting question is to ask why doesn't the foundation ever talk about off-chain transactions? My guess is they know that FinCEN has them in a nasty bind now that they've made it clear that Bitcoin is ok provided you use it exactly the way they want you to: as an easily traceable blockchain-only payment method. Promoting alternatives would raise ugly issues around money laundering and so on. Right now if someone went off and implemented one of Peter's anonymous chaum-token using fidelity bonded banks it would most likely be used not as a payment system, but as a way to launder money.

Yet it would also provide an answer to the scalability issue, just not one the Foundation can back, and probably not a solution that the Foundation's publicly visible and mostly US-based members can use to accept payments anyway regardless of how well it works. That gets back to the issue of his repeated thunderous public statements of course. What do they do? They discourage anyone from working on alternatives. If they don't exist, people won't have any option but to raise the blocksize.

The worst scenario for the Foundation is if off-chain transactions are developed to the point where they are a secure and usable way of moving funds, yet the legal situation in the US doesn't change or gets worse. The rest of the world could easily choose to leave the blocksize as it is, gradually pricing companies who must follow strict anti-money-laundering laws out of Bitcoin entirely.

As for you Peter, and indeed anyone else who cares about Bitcoin's future, don't let yourself get distracted by forums. Your efforts to make the problems Bitcoin has as a payment system clear, like the replace-by-fee project and making mining more decentralized with pooled-solo mode, are good and you should keep them up. Writing code and non-forum PR is a far more valuable use of your time than chatting to angry internet trolls like ShadowOfHarbringer and Gavin.

edit: Speaking of, I agree with that anonymous timestamper. You should be encouraging UTXO timestamping and other abusive uses of Bitcoin that we know threaten Bitcoin in the future now, precisely to make the risk clear. With Bitcoin it's not unlike security disclosure, where not disclosing the security risks puts us in much greater harm in the future. Gregory Maxwell's concept of our "startup capital" has value, but at the same time we should get a sense now of how valuable people see abusive use when we know we have no way of stopping them in the future other than by making the use expensive. So yes, turn off your timestamping servers until someone is willing to pay you properly to run them.

edit #2: Note how I'm not saying that the foundation is trying to get Bitcoin under FinCEN/US government control, just that they are taking a perfect rational approach towards promoting the blockchain as the solution to all payments given the limitations public companies in the US face.