tl;dr: Mine with Replace-by-Fee v0.9.1 and you'll earn 1% more per block found, or 0.25BTC.

I'm running an experiment right now with replace-by-fee. Basically I'm doing continuously testing it, such that at any one time the extra fees from the test represents about 1% of the block reward. A site considering using the "scorched earth" defense to make accepting zeroconf transactions safer wanted me to get an idea of how willing miners would be to upgrade - I figured 1% would be an interesting starting point.

You'll need to compile and run the above tree. It's based on the v0.9.1 release with one small patch. Other replace-by-fee peers are automatically found on the network - you don't need to add replace-by-fee peers explicitly for it to work.

As for what this is all about, replace-by-fee simply means that rather than only accepting the first transaction you see to your mempool, you accept whatever one pays the most fees. It's a simple rule that results in the most profit per block, lets users re-issue transactions with higher fees if needed, and makes it clear to everyone that relying on unconfirmed transactions by themselves is insecure rather than giving people a false sense of security. Most importantly it ensures people use Bitcoin in a secure way, relying on crypto and incentives rather than relying on trust, which will help keep Bitcoin mining free of regulation and decentralized.

More info:

Why you should mine with replace-by-fee

Double-spending unconfirmed transactions is a lot easier than most people realize

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

I noticed that the ngccbase Colored Coin client(1) added a
python-bitcoinlib dependency, specifically my fork. In addition there is
also now a rudementary python-bitcoinlib package in archlinux.

So with that in mind I'm releasing v0.1, perhaps somewhat arbitrarily:
                                                                     
    https://github.com/petertodd/python-bitcoinlib/tree/v0.1         

This Python2/3 library provides an easy interface to the bitcoin data
structures and protocol. The approach is low-level and "ground up", with
a focus on providing tools to manipulate the internals of how Bitcoin
works in a Pythonic way, without straying far from the Bitcoin Core
implementation.

The current status of the library as of v0.1 is that the support for
data-structures related to transactions, scripting, addresses, and keys
are all quite usable and the API is probably not going to change that
much. Bitcoin Core RPC support is included and automatically converts
the JSON to/from Python objects when appropriate.  EvalScript(),
VerifyScript(), and SignatureHash() are all functional and pass all the
Bitcoin Core unittests, as well as a few that are still yet to be
merged.(2) You'll find some examples for signing pay2script-hash and
p2sh txouts in the examples/ directory; I personally used the
transaction signing functionality to make up a set of unittests related
to OP_CODESEPARATOR and FindAndDelete() recently. Finally my dust-b-gone
script(3) is another good example, specifically of the RPC
functionality.

I personally haven't had any need for the p2p network related code for
some time, so I'm sure it's not in a good state and it lacks unittests;
Bloom filters for one are missing the merkle-block support to actually
make them useful. But the RPC support makes up for that for many uses.

This release and others in the future are signed by my PGP key, as well
as every publicly pushed commit. You can verify the key via WoT, my
bitcointalk account, signing history in the Bitcoin Core repo, and
mailing list records among other sources.

Disclaimer: This is alpha code in a language not known for type-safety.
            I wouldn't personally use python-bitcoinlib for anything
            other than experiments and neither should you.

1) https://github.com/bitcoinx/ngcccbase
2) https://github.com/bitcoin/bitcoin/pull/3861
3) https://github.com/petertodd/dust-b-gone

- --
'peter'[:-1]@petertodd.org
000000000000000097649e8d66395b3cb4527263409adf628c76cc56af0434fe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJTJFkFXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDA3OGEyNGUxNTBlNTc2ZGVjZWUyYWQzMGNhMmE2YTRhMmM3
NGVkYmJkNjM2NDViNjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftZiwgAk8YVN9t76tKIKcWKyrGgv8yk
UZGZkkrowED0lyhMXfmviezeWhjvHZgQrwha2hAuik36WEBN1jnv9wuJ6g9tnxGY
PyG8n1SV2rtQ/QIJyL6wOuqL3UZi6d6IdZ/udVmyGwz+XhE89AwitR0++MvxkPNv
i9R3Gw5Z1CnS2W0jGpAT88k3q3pqEzbYutP/FaylL2+6MuSUGwHUoY8dqcRkwkw1
eIrd2W33x4NvuxYPLnHR64uE0B8KoreZOyyskMdeMsKtZNflkfgfMiD10xnw2PGx
z8S42wPbrI5ZYLL1OLdRfuKMdQ4qOyF4jfV+QRZWQ5t5Qh1akVWmz7ffFHGo0Q==
=k1pi
-----END PGP SIGNATURE-----

http://bits.blogs.nytimes.com/2013/11/23/study-suggests-link-between-dread-pirate-roberts-and-satoshi-nakamoto/

After Mr. Ulbricht was arrested last month, the scientists used public information to begin tracing Silk Road-related transactions. Among their discoveries was a particular transfer to an account controlled by Mr. Ulbricht from another that had been created in January 2009, during the very earliest days of the bitcoin network, which was set up the previous year.

In tracing various transactions made to and from Mr. Ulbricht’s account, the authors found an intriguing one involving the transfer of 1,000 bitcoin, which would have been worth $60,000 when it was made on March 20 of this year, but is now worth roughly $847,000.

Proof that Satoshi was DPR wouldn't be a bad thing for Bitcoin; there's way too many people in this community who treat every word and every decision made by Satoshi as gospel rather than evaluating ideas on their own merits.

Having said that, if you had as many Bitcoins as Satoshi probably has $60k wouldn't be that much money to you; laundering it through the Silk Road as a starting point might make a lot of sense if you were still trying to stay anonymous and wanted to retain access to your funds.

EDIT: Academic paper's been posted: https://s3.amazonaws.com/s3.documentcloud.org/documents/839348/silk-road-paper.pdf

I'm not overly impressed... Given the suspicion is that the FBI confiscated the Silk Road "hot wallets", it sounds very plausible to me that this link is simply Satoshi (or some other very early adopter) making use of the Silk Road as a mixing service - they haven't at all ruled out that possibility.

tl;dr: The following language was added to the bylaws to make it clear that the the Bitcoin Foundation supports a decentralized and free Bitcoin:

Section 2.2  The Corporation shall promote and protect both the decentralized, distributed and private nature of the Bitcoin distributed-digital currency and transaction system as well as individual choice, participation and financial privacy when using such systems. The Corporation shall further require that any distributed-digital currency falling within the ambit of the Corporation's purpose be decentralized, distributed and private and that it support individual choice, participation and financial privacy.

- https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/commit/ac2b734659d6f0fe250ca29337a5739e9f10e742

I think the final language chosen is a good compromise between John Dillon's original pull request, which in hindsight was probably too specific even if I thought its intent was good, and not having this section at all. Kudo's to Patrick Murck for suggesting it - I spoke to Patrick at the May conference and I found him to be reasonable and thoughtful. The discussion that lead to the acceptance of the pull request is worth reading: https://github.com/pmlaw/The-Bitcoin-Foundation-Legal-Repo/pull/4

It'll never be easy to agree on specific actions, but agreeing that a decentralized and free Bitcoin is a fundamental goal that all foundation members should share is a great starting point.

Reddit post: http://www.reddit.com/r/Bitcoin/comments/1n9wgp/the_bitcoin_foundation_has_finally_officially/

[Stage 1: Analysis]

https://bitcointalk.org/index.php?topic=265488.msg3164831#msg3164831

I was reading the above post describing efforts to come up with a new Mastercoin tx scheme; there are a lot of issues with the above, in particular misconceptions about how Bitcoin works, as well as missed opportunities to add censorship resistance. In addition there are potential upcoming changes to Bitcoin that could seriously harm your protocol - changes that may end up getting more support than otherwise because they do exactly that.

I'd can create a complete specification taking all these issues into account, including explaining those issues are exactly and what trade-offs (and alternatives) were involved in coming up with the spec. In short I plan to answer the question "How do you implement a blockchain on top of Bitcoin in a robust, low-resource, and censor-proof way?"

If you are interested let me know and we can work out a set of concrete deliverables: specification document, design rational, and (optionally) example code written in Python with python-bitcoinlib implementing the proposed specification. Any contract would be fixed price, no-cure-no-pay, with a third party approved by both parties acting as escrow in a 2-of-3 multisig transaction deciding if I had in fact completed it successfully. Jeff Garzik has done work along these lines in the past (pybond) and may be able to take on that role.

I'm not revealing the source, since it was a PM, but it was someone who I believe to have a pretty good grasp of the inner workings - better than my own understanding at any rate. It's also someone who is not particularly enthusiastic about this project, so I imagine their price for the work described would be more than we would be willing to pay. I of course invited them to participate in the contest, but I doubt they will.

I suggest we give Tachikoma's method a shot and see what happens. It may be that we have to change our encoding method again if our skeptical friend is right and future bitcoin changes make this method unworkable. Of course, if anybody has a better idea, I'd love to hear it.

As some of you either know or suspected all along that PM was sent to J.R Willett by myself. He said he probably wasn't going to need my services, but would welcome a fleshed out proposal all the same. Keeping the proposal secret seemed like a bit too much of cloak-n-dagger sillyness to me, and in any case I thought my services might be of interest to MasterCoin investors or even those with unrelated projects using the same concepts, so I'm just going to present it in public and allow the community to consider it.

Stage 1: Analysis

To design a specification for how MasterCoin transactions are to be encoded I first have to analyze the larger MasterCoin protocol. Of course a part of the protocol has already been implemented and used in production: the Exodus Address. But that's simply an initial bootstrapping mechanism to define who owns what MasterCoins - the rest of the MasterCoin protocol and design is essentially unspecified at present. (based on the materials available to me at mastercoin.org, including the wiki and the various versions of the whitepaper, and materials on this forum)

I will first review and solidify the requirements for what MasterCoin is meant to be: What type of consensus model does MasterCoin actually need? Does it need what at all? What information do participants require to make and validate a transaction? Because MasterCoin is meant to be a protocol by which other currencies can be created, the answers to these questions in turn decide what those currencies, and trades between those currencies, are actually capable of. Of course it's not my job to decide what MasterCoin is, but rather to give the MasterCoin community an honest assessment of what options are available and what consequences those choices have.

Part of this analysis includes an honest assessment of whether or not "MasterCoin's" - created by a transfer to the Exodus address prior to August 31st 2013 - are in fact actually required at all. Anyone who has invested in MasterCoins, or is considering doing so, should think hard about this question given that the only thing making their investment valuable is the requirement for MasterCoins. If it is the case that MasterCoins are not an essential part of the protocol it is quite likely that copy-cat's will arise later with many or all of the features that the "official" MasterCoin protocol provides. In this case the value of their investment may be severely diminished and investors would be wise to sell their coins to others while they can still get a good price for them.


Stage 2: Bitcoin blockchain transaction specification

If Stage 1 determines that the Bitcoin blockchain is required in some way the next step is to flesh out how exactly that data will be encoded. Of course, the stage 1 analysis needs to be done taking the options available in stage 2 into account, but it is in this stage where the specific details of those choices are fleshed out. Considerations here include fee efficiency, Blockchain space efficiency, verifiability, and scalability. In addition censorship resistance is important - given the hostility towards MasterCoin's proposed and current use of the blockchain the scheme chosen should be ideally designed to be difficult or impossible for miners to exclude from the transactions they mine. Finally where possible advanced cryptography should be considered, such as non-interactive proofs, so that even if such cryptography is not used now it can be implemented in the future to better achieve technical goals.


Compensation

40BTC for the stage 1 report, and approximately 25BTC for the stage 2 specification, although that figure is subject to change depending on the results of the initial report. In addition I am willing to offer discounts for reports made public: 50% if they are made public immediately, and 25% if they are to be made public at some pre-agreed time in the future. Payment must be made upfront to a 2-of-3 multisig address, with the third pubkey controlled by an third-party escrow agent; expect an additional 5% fee to compensate that agent.

I am open to doing reports for the community as a whole; investors in particular may be interested in an independent analysis of MasterCoin's long-term viability to better decide if they should retain their positions. Such an effort could be done as a KickStarter style pledge where either the report is fully funded, or partial amounts are simply returned to those who pledged them.


Thank you for your time,

Peter Todd

Rewards at the following P2SH addresses are available for anyone able to demonstrate collision attacks against a variety of cryptographic algorithms. You collect your bounty by demonstrating two messages that are not equal in value, yet result in the same digest when hashed. These messages are used in a scriptSig, which satisfies the scriptPubKey storing the bountied funds, allowing you to move them to a scriptPubKey (Bitcoin address) of your choice.

Further donations to the bounties are welcome, particularly for SHA1 - address 37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP - for which an attack on a single hash value is believed to be possible at an estimated cost of $2.77M (4)

Details below; note that the "decodescript" RPC command is not yet released; compile bitcoind from the git repository at http://github.com/bitcoin/bitcoin

SHA1:

$ btc decodescript 6e879169a77ca787
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA1 OP_SWAP OP_SHA1 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "37k7toV1Nv4DfmQbmZ8KuZDQCYK9x5KpzP"
}


SHA256:

$ btc decodescript 6e879169a87ca887
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_SHA256 OP_SWAP OP_SHA256 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "35Snmmy3uhaer2gTboc81ayCip4m9DT4ko"
}


RIPEMD160:

$ btc decodescript 6e879169a67ca687
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_RIPEMD160 OP_SWAP OP_RIPEMD160 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3KyiQEGqqdb4nqfhUzGKN6KPhXmQsLNpay"
}


RIPEMD160(SHA256()):

$ btc decodescript 6e879169a97ca987
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH160 OP_SWAP OP_HASH160 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "39VXyuoc6SXYKp9TcAhoiN1mb4ns6z3Yu6"
}


SHA256(SHA256()):

$ btc decodescript 6e879169aa7caa87
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_HASH256 OP_SWAP OP_HASH256 OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3DUQQvz4t57Jy7jxE86kyFcNpKtURNf1VW"
}

and last but not least, the absolute value function:

$ btc decodescript 6e879169907c9087
{
    "asm" : "OP_2DUP OP_EQUAL OP_NOT OP_VERIFY OP_ABS OP_SWAP OP_ABS OP_EQUAL",
    "type" : "nonstandard",
    "p2sh" : "3QsT6Sast6ghfsjZ9VJj9u8jkM2qTfDgHV"
}

For example, this pair of transactions created, and then collected, an
absolute value function bounty:

0100000001f3194f7c2a39809d6ea5fa2db68326932df146aaab7be2f398a524bd269d0b6200000 0008a473044022039bc13cb7fe565ff2e14b16fbc4a9facd36b25a435d2f49de4534463212aeaee 022076413c7591385cd813df37d8104dd8110745c28178cef829b5ab3e56b7c30d22014104d3477 5baab521d7ba2bd43997312d5f663633484ae1a4d84246866b7088297715a049e2288ae16f16880 9d36e2da1162f03412bf23aa5f949f235eb2e7141783ffffffff03207e7500000000001976a9149 bc0bbdd3024da4d0c38ed1aecf5c68dd1d3fa1288ac0000000000000000126a6e879169907c9087 086e879169907c908740420f000000000017a914fe441065b6532231de2fac563152205ec4f59c7 48700000000

0100000001f18cda90bbbcfb031c65ceda17c82dc046c7db0b96242ba4c5b53c411d8c056e02000 0000c510181086e879169907c9087ffffffff01a0bb0d00000000001976a9149bc0bbdd3024da4d 0c38ed1aecf5c68dd1d3fa1288ac00000000

Specifically with the scriptSig: 1 -1 6e879169907c9087


Notes:

1) We advise mining the block in which you collect your bounty yourself; scriptSigs satisfying the above scriptPubKeys do not cryptographically sign the transaction's outputs. If the bounty value is sufficiently large other miners may find it profitable to reorganize the chain to kill your block and collect the reward themselves. This is particularly profitable for larger, centralized, mining pools.

2) Note that the value of your SHA256, RIPEMD160, RIPEMD160(SHA256()) or SHA256^2 bounty may be diminished by the act of collecting it.

3) Due to limitations of the Bitcoin scripting language bounties can only be collected with solutions using messages less than 521 bytes in size.

4) "When Will We See Collisions for SHA-1?" - Bruce Schneier -https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

It would be useful if multiple payments to the same address could be summed together. For instance with CoinJoin if Alice, Bob and Charlie wish to, say, pay 1BTC to Wikileaks they can create a single 3BTC txout with Wikileak's public address. However they have to do that interactively.

So I'm proposing SIGHASH_SUM, a new SIGHASH bit that would allow a given txin signature to specify that at least nBTC of value should be added to a txout signed for. Thus if three txin signatures each specify that 1BTC should be added to the txout with Wikileak's public address, the transaction is valid if there exists a single 3BTC txout. Similarly any company accepting multiple payments at once could combine all their customers payments together into a single transaction, with a single txout, thus saving blockchain and UTXO space as well as improving privacy.

Of course this isn't too useful by itself, but the idea can be combined with more sophisticated SIGHASH bits that say that a particular set of txin's and txout must exist, rather than the more restrictive modes available today. But my lunch break is over so I'll write more about that later.

https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report.tar.bz2 or https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report.zip

Individual files:

https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report/report.txt.asc
https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report/40809aed-1b5cb086.diff
https://s3.amazonaws.com/peter.todd/litecoin-v0.8.3.7-audit-report/litecoin-0.8.3.x-code-audit-agreement.txt.asc

report.txt.asc SHA256 hash: 24832b4b8411f3fbcc98b96bdfaaf90f4aeac39a7fbfb491bff5a76d23859dbd

I thought this would be of interest to Bitcoin people as well; AFAIK this is the first attempt anyone has made to formally audit a crypto-coin release in any way. I can't claim to have any special skills in that regard other than a good knowledge of Bitcoin, but it's a decent first try at least.

[DO NOT TRUST RE-IMPLEMENTATIONS OF BITCOIN WITH YOUR MONEY]

webbtc.com runs on bitcoin-ruby, a re-implementation of Bitcoin, and as we keep saying over and over again, re-implementations are dangerous because they invariably have bugs and don't duplicate bitcoin-qt behavior exactly.

I forked webbtc.com on testnet yesterday, still not quite sure how I pulled that off, but I was playing with non-standard transactions.

I also forked webbtc.com on mainnet today with transaction 315ac7d4c26d69668129cc352851d9389b4a6868f1509c6c8b66bead11e2619f It has two inputs, both using SIGHHASH_SINGLE, and only one output. SignatureHash() in script.cpp has the following code:


if (nOut >= txTmp.vout.size())
{
    printf("ERROR: SignatureHash() : nOut=%d out of range\n", nOut);
    return 1;
}


The thing is, that's not actually an error. SignatureHash() returns the hash of the signature, and CheckSig() doesn't check the return code, so it acts as though the hash the signature signed was 0000000000000000000000000000000000000000000000000000000000000001 You can create a signature for that, and it works just fine and the transaction is considered valid.

bitcoin-ruby and libbitcoin, and probably a few more, all treat this case as an actual error and fail, so they get forked from the main network and are vulnerable to an attacker creating fake confirmations.

I was auditing litecoin this weekend, and in the process found a half-dozen obscure edge cases in Bitcoin's scripting code that I didn't know about it, and I'm already an expert on how Bitcoin works. Frankly the science of software engineering just isn't at the point where we know how to re-implement bitcoin and get it right. This is a problem at least as hard as writing safety-critical flight avionics software; in my opinion it's probably harder.

DO NOT TRUST RE-IMPLEMENTATIONS OF BITCOIN WITH YOUR MONEY
DO NOT WRITE FULL-NODE RE-IMPLEMENTATIONS OF BITCOIN
YOU ARE NOT SMART ENOUGH TO MAKE THEM SECURE, NOBODY IS

Right now between two to four running the largest pools control Bitcoin in the short term. That's a lot of hashing power in the hands of very, very few people. In addition pools have little incentive to run secure operations, and many pools have been hacked with their funds stolen. Those hacks could just have easily been used to attack the network itself.

This needs to change.

Pooled-solo mining is a concept Gregory Maxwell, Luke Dashjr and I were discussing at the conference two weeks ago. (credit goes to Greg and Luke; I was mostly just listening) Basically the idea is that miners with mining equipment run a local Bitcoin node and use that node to construct the blocks they mine - the same as if they were solo mining. The pools job is then to only track shares and organize payouts.

If the pool gets hacked the worst that can happen is miners are ripped off, rather than Bitcoin itself being attacked. With pooled-solo mining even a pool with a majority of hashing power wouldn't be able to do much harm to Bitcoin. (depending on the implementation they may be able to blacklist specific transactions - the pool needs to know what transactions are in the share to credit fees properly)

Tech-wise Luke created getblocktemplate last year as a means to audit mining pools. I'm sure Greg and Luke can explain the nitty gritty details better than I can, but essentially the plan is to take getblocktemplate and extend it as required for pooled-solo mining. This will include pool and miner software initially, and later improvements to GUIs and what not to make the whole process easier.


With the success of my recent video project I also want to make this Keep Bitcoin Free's next project, specifically funding a developer (likely Luke) to make this happen. Additionally once software is written and easily usable a good follow-up would be a video and other media to promote the idea to miners. No guarantees we'll be able to come up with commercially competitive remuneration, but we can at least come up with a "Thank you" tip. But first lets discuss the technical requirements to get an idea of what the scope is.


Finally, for the record, a big part of the reason why myself and other Keep Bitcoin Free supporters are interested in doing this is very much to take power over the direction of the network from big pools and put it into the hands of thousands of individual miners. It's much easier to convince people that changes to Bitcoin, like increasing the blocksize, are directly impacting decentralization when individual miners are seeing that happen to themselves.

Video: http://www.youtube.com/watch?v=cZp7UGgBR0I

Website: http://keepbitcoinfree.org/

Pretty simple right now, but this is the beginning. For those of you at the 2013 conference, I'll be giving a presentation about off-chain transactions on Saturday as part of the tech stream.

Reposting a bitcoin-development email: http://sourceforge.net/mailarchive/forum.php?thread_name=20130515113827.GB26020%40savin&forum_name=bitcoin-development


Now that I have the replace-by-fee reward, I might as well spread the
wealth a bit.

For all this discussion about replace-by-fee and the supposed
security of zero-conf transactions, no-one seems to think much about how
in practice very few vendors have a setup to detect if conflicting
transactions were broadcast on the network simultaneously - after all if
that is the case which transaction gets mined is up to chance, so much
of the time you'll get away with a double spend. We don't yet have a
mechanism to propagate double-spend warnings, and funny enough, in the
case of a single txin transaction the double-spend warning is also
enough information to allow miners to implement replace-by-fee.

So I'm offering 2BTC for anyone who comes up with a nice and easy to use
command line tool that lets you automagically create one version of the
transaction sending the coins to the desired recipient, and another
version sending all the coins back to you, both with the same
transaction inputs. In addition to creating the two versions, you need
to find a way to broadcast them both simultaneously to different nodes
on the network. One clever approach might be to use blockchain.info's
raw transaction POST API, and your local Bitcoin node. A good starting point
for your work would be Gavin's spendfrom utility in the contrib/spendfrom
directory in the Bitcoin-QT respository.

If you happen to be at the conference, a cool demo would be to
demonstrate the attack against my Android wallet. I'll buy Bitcoins off
of you at Mt. Gox rates + %10, and you can see if you can rip me off.
Yes, you can keep the loot. This should be videotaped so we can put
an educational video on YouTube after.

Finally please do keep in mind that it's much better for the community if
an attack is demonstrated first, followed by releasing the code some
time later.

Every talk will be widely witnessed and videotaped so we can get some reasonably good security by simply putting out PGP fingerprints in our slides. Yeah, some fancy attacker could change the videos after the fact, but the talks themselves will have wide audiences and a lot of opportunities for fraud to be discovered. That means it'd also be reasonable for people to sign those keys too if you are present and are convinced you aren't looking at some impostor. (of course, presenters, check that your PGP fingerprints are correct...)


Remember that PGP depends on the web-of-trust. No single measure in a web-of-trust is needs to be absolutely perfect; it's the sum of the verifications that matter. I don't think it matters much if you have, say, seen Jeff Garzik's drivers license as much as it matters that you have seen him in a public place with dozens of witnesses that would recognize him and call out any attempt at fraud.

Secondly remember that many of us are working on software where an attacker can steal from huge numbers of users at once if they manage to sneak some wallet stealing code in. We need better code signing practices, but they don't help without some way of being sure the keys signing the code are valid. SSL and certificate authorities have advantages, and so does the PGP WoT, so use both.


FWIW I take this stuff pretty seriously myself. I generated my key securely in the first place, I use a hardware smartcard to store my PGP key, and I keep the master signing key - the key with the ability to sign other keys - separate from my day-to-day signing subkeys. I also PGP sign emails regularly, which means anyone can get a decent idea of if they have the right key by looking at bitcoin-development mailing list archives and checking the signatures. A truly dedicated attacker could probably sign something without my knowledge, but I've certainly raised the bar.

Reposting http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02159.html


It has been previously(1) proposed that hashcash using the same PoW
function as the Bitcoin block hashing algorithm be used to create
hashcash whose value is denominated in Bitcoins. This poses two problems
however: widespread use of such hashcash would harm overall network
security and determining the value of the hashcash requires knowing the
revenue miners can gain from transaction fees at a given block height -
a non-computable function. However, with some modifications we can
extend the idea to directly denominate the hashcash in Bitcoins at the
cost of a small increase in proof size.

Recall that the fundemental problem is the need to do some work to make
digest D have value V, resulting in a proof that can be given to a third
party. We want V to be denominated in Bitcoins, and we want the actual
economic cost to create P to be as close as possible to the face-value
V. Finally should computing P result in a valid Bitcoin block header,
the creator of the proof should have a strong incentive to publish their
header to the P2P network and extend the current best chain.


# Proof structure

Lets look at the elements of the proof from the block header to the
digest.


## PoW Block Header

This must be a valid block header. It is particularly important to
ensure that the header can be linked to the actual blockchain, although
the header itself does not need to be a part of the chain, and hence the
block hash does not need to meet the difficulty requirements.


### Previous Block Headers

The proof may optionally include one or more previous block headers in
the event that the PoW block header's previous block is an orphan.
Unlike the PoW block header, these block headers MUST meet the
difficulty requirements although an implementation MAY skip actually
checking the difficulty if a difficulty retarget has not happened or the
PoW is timestamped. (see below)


## Partial Transaction and Merkle Path

The partial transaction consists of a SHA256 midstate followed by
exactly one transaction output. The merkle path to the PoW block header
MUST prove the transaction was the coinbase transaction and not any
other transaction.


## Transaction Output

The last transaction output must have a scriptPubKey consisting of
exactly one PUSHDATA op which pushes H(D | N) to the stack. Its value,
V', is the basis for determining the value of the proof of work. V' must
satisfy V' < k*Vi(h) where Vi is the inflation reward for the PoW block
height and k < 1 For a number of reasons, including making sure there
are strong incentives for broadcasting succesful PoW solutions, the
value of k should be chosen fairly conservatively; the author suggests k
=3D 1/10 as a ballpark figure. Finally N is some fixed value specific to
hashcash of this form to ensure the txout proof can-not be reused.

Vi can also be calculated as the median of the last n "anyone-can-spend"
outputs seen in coinbases when the value of the inflation reward falls
low enough that using the inflation reward is impractical.


## Timestamp

If the proof-of-work is used after a difficulty retarget the PoW needs
to be timestamped in the block chain with a merkle path leading to a
valid block header. The difficulty used for calculating the value of the
PoW then becomes the minimum of the difficulties of the PoW previous
block and the timestamp.


# Determining the actual value of the PoW

The proof proves that work was done to find a valid block header. That
block header, had it met the difficulty threshhold, could have created a
valid block worth at least the inflationary reward Vi(h) to the miner.

The coinbase transaction output and merkle path shows that were such a
block found, the miner would have then given away V' to whomever managed
to create a transaction spending it when the coinbase matured. The
coinbase takes 100 block to mature, so the chance of any one miner
collecting it is proportional to the hashing power they control.(*)

*) As with fidelity bonds we make the assumption that no party controls
more than 50% of the hashing power - the assumption underlying Bitcoin's
security anyway. If this assumption is proven incorrect or
insufficiently strong, possibly due to a cartel of miners banding
together to create low-cost PoW's, the output can use the provably
unspendable/prunable OP_RETURN <digest> scriptPubKey instead with a
non-zero value.

With P(block hash, target), the expected probability of a valid PoW
being found given the work required to create the block hash with the
given difficulty target, we can finally calculate the value of the PoW
in terms of expected cost: V =3D P(hash, target) * V'


# Pool implementation and 51% attack security

Because doing the work required to create coinbase txout hashcash is
sufficient to also create a valid block a pool can safely rent out
hashing power to create hashcash of this form on demand without making
it possible to rent large amounts of hashing power directly on short
notice. (though some extensions to GetBlockTemplate for hashers
verifying it may be required)

Because the anyone-can-spend txout is the basis for the value of the
hashcash the value remains computable even if transaction fees become a
larger proportion of the block reward in the future.

Unlike announce-commit sacrificies(2) proofs with very small values can
be easily created; the pool operator can make a trade-off between the
profit varience - remember that a block header with a valid PoW
represents a loss - and latency by adjusting the proof of work
difficulty and V'.

As an aside, note how the mechanism of a anyone-can-spend txout in a
coinbase can replace the announce portion of an announce-commit
sacrifice; a coinbase transaction is the only case where a single merkle
path proves that the transaction output was possible to spend in a
subsequent block, but was not yet spent; also an argument for allowing
coinbase transaction inputs.


# Application: Paying for additional flood-fill bandwidth

Additional messaging applications built on top of the Bitcoin P2P
network would be useful, yet there needs to be some general mechanism to
make DoS attacks expensive enough that they are impractical. For
instance a useful P2P network feature would be a mechanism to propose
trust-free coin mixes transaction outputs, propose specific txout sets,
and finally a mechanism to broadcast valid ANYONECANPAY signatures so
the inputs and outputs can become a valid transaction. By separating the
txout and signature broadcasts, who is paying for what output is made
very difficult to determine.

Of course such a mechanism will likely come under attack by those trying
to combat anonymity. However with the coinbase txout hashcash mechanism
those attackers are forced to either contribute to the security of the
Bitcoin network or incur much higher opporuntity costs for conducting
their attack than honest nodes pay. (remember how the choice of k =3D 10
makes for a large ratio of maximum V' value to Vi(h) inflation reward)

To reduce amortized proof size one proof can be used for multiple
payments with Rivest PayWords and similar techniques.


# PowPay - Off-chain, anonymous, probabalistic payments

By setting the special txout to a scriptPubKey spendable by the
recipient we can prove to a third party that work was done that with
probability P(hash,target) could have resulted in a txout spendable by
them of value V' Thus the expected value of the payment is V =3D P(h,t)*V'
The recipient needs to make the proof non-reusable, either by recording
all proofs submitted, or by requiring a nonce in the scriptPubKey: (*)

    <nonce> DROP {additional ops}

*) Note the implications for the IsStandardInput() test.

Because the recipient has no way of knowing how the sender paid to have
the hashing done on their behalf the source of the funds is unknown to
them. Additionally the payment can be of any amount less than a full
block reward, and the time varient between actual payments can be
reduced to, in theory, as little as the block interval itself with 100%
miner participation.


## Maximum Payment amount

Unlike coinbase txout hashcash the maximum value of a PowPay transaction
is strictly limited by the inflation reward; the trick of calculating
actual cost by prior sacrifices doesn't work because no honest sacrifice
is involved. In any case it is desirable for the mechanism to account
for a large percentage of total transaction value.

The issue is that should a valid block be found either the miner must
still have a strong incentive to broadcast that block that can be proven
to the recipient, or the miner must not be the one who controls that
decision.

The latter option is possible by inverting the relationship: now the
recipient constructs the block, and the sender simply arranges for a
valid PoW to be created - essentially the recipient acts as a mining
pool with an extremely high minimum work, and the sender provides
hashing power. With the 1MB blocksize the cost to operate the full
validating node required is low and attacks on block propagation are
difficult to successfully pull off.


### Supporting PowPay volume in excess of inflation reward + tx fees

To support overall PowPay volumes that are in excess of the inflation
reward and transaction fees the sender can provide the recipient with
signed transaction inputs subject to the constraint that only blocks
with PoW's generated by the sender can be used to spend them. For
instance a nonce in a well-known place can be provided by the sender and
included in a modified block header. By modifying the block hashing
algorithm so that PoW-withholding is not possible - a significantly more
serious problem in this application - the sender still is forced to send
all potential solutions to the recipient, including possible winning
ones. Provided that attacking block propagation is difficult the sender
can't prevent the reciver from spending their transaction inputs.


## Scalability

PowPay can provide much greater scalability than Bitcoin itself, in
terms of payments per second, however it is still limited in terms of
actual fund transfers to recipients per second. A naive implementation
would give a actual transfer every ten minutes maximum, and a highly
sophisticated solution 7/second. (albeit probably requiring a hardfork
to solve PoW withholding and/or use of third parties)

At the same time the proofs required become large with an increased
blocksize, and in the case of the inverted "recipient builds blocks"
mode the recipients either incur large costs running full nodes, or
greatly disrupt transaction flow for on-chain users by mining blocks
with no transactions in them at all. (remember that a recipient who
trusts someone else to construct the blocks for them is trusting that
third-party to do so correctly)

The latter is especially problematic because as the blocksize is
increased a higher percentage of the cost of mining goes to the overhead
required to run a validating node, rather than hashing, which has the
perverse effect of decreasing the cost of mining blocks with no
transactions in them at all. (or transactions that the miner knows have
not been revealed to other miners)

The analysis of this strange mixed bag of incentives is highly complex.


# Paying for mining

TxOut HashCash and PayPow both require the sender to somehow get someone
to mine on their behalf. The exact nature of these relationships will
vary and are beyond the scope of this paper.


# Eliminating PoW withholding

While the above examples have used economic incentives possible within
the existing Bitcoin system a structural incentive is possible as well.
A nonce N is chosen by the party paying for the PoW, such as a pool or
PowPay recipient, and H(n) is included in the block header.(*) The PoW
function is then modified to consider the PoW valid if the sum of the
expected hashes required to find H(B) and H(B | n) exceeds the current
difficulty target.

*) Note how the block header can be extended, while remaining fairly compat=
ible
with existing ASIC mining hardware, by taking advantage of the fact that
ASIC's use the SHA256 midstate at a starting point for their PoW
calculations.(3)




1) "Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
for pruned nodes)" - 2013-06-06 - Peter Todd <pete@petertodd.org> -
bitcoin-development email list

2) "Purchasing fidelity bonds by provably throwing away bitcoins" -
https://bitcointalk.org/index.php?topic=3D134827.0 - Peter Todd

3) "Re: 32 vs 64-bit timestamp fields" - 2013-06-09 - John Dillon
<john.dillon892@gmail.com> - bitcoin-development email list

I think Gavin has alluded to possibly rewarding those who run full nodes, which I think is the way to go. I don't see any reason why miners should get rewarded, yet those who run full nodes and eat the bandwidth/disk space get nothing.

When running a node becomes expensive enough that people can't do it for free you'll still be able to find full nodes willing to accept incoming connections. You'll pay for that service in a variety of ways:

1) Transaction fees: You connect directly to a miner who lets you do so because they want your transaction fees. They may require some # of transactions per unit time, and part of the agreement may be that you only send transactions to them. (easily verified) In return they'll run your bloom filter against incoming blocks, although don't be surprised if they force you to give them a bloom filter specific enough to identify exactly what addresses are in your wallet as part of the deal.

2) Pay-for-service: You pay for the service directly. In return they resend your transactions to miners to get them mined, possibly with preferential deals (kickbacks) that may or may not be public knowledge. They also run your bloom filter against the blockchain, and again, they may or may let you do so in a non-specific manner. Given AML regulations I wouldn't be surprised if the services that operate out in the open only allow you to tell them what addresses you are interested rather than a bloom filter obscuring that information. (AML rules apply to case #1 too)

3) Datamining: Google and other search engines already provide a lot of services purely in return for the data they can gather. The blockchain itself is a rich source of transaction data, made richer by figuring out the real identities behind the pseudonymous addresses on it. Just like #1 and #2 if you can determine who is sending what transactions and owns what addresses you can integrate that into a rich dataset to do things like get real-world information on what vendors are actually popular, which in turn can feed search engine results and other services.

It'll be interesting to see how AML regulations apply to all these services in the future. I suspect they'll eventually be subject to the same know-your-customer rules as any other financial service provider to help authorities link identities to Bitcoin addresses. This doesn't have to be very intrusive: in case #3 that might be as simple as using your Google login to authenticate with Google's Bitcoin servers.

There was an interesting post on the Bitcoin Foundation's private forum today:

Hi! I would like the board to discuss opening up lines of communication with money regulators - particularly FinCEN and AUSTRAC (I'm from Australia). FinCEN and other government money regulators need to write new rules as they obviously don't understand Bitcoin's inherent structure.

I think it would be better if some organisation like the Bitcoin Foundation could offer guidance draft rules and work with the regulators.

Otherwise we'll have a situation pretty soon where they try to implement something unworkable, the criminals flood into the Bitcoin system then the argument for 'shutting down bitcoin' grows in popularity.

-Bitcoin Foundation board meeting agenda requests (only viewable by foundation members)


You know, Bitcoin is at an interesting stage of it's development. We've got a lot of money flowing in to the ecosystem and for the first time we're seeing interest from big businesses - even PayPal and Western Union are looking into accepting Bitcoin.

We're also under a lot of attack; big heavily protected exchanges and other websites like Mt. Gox, blockchain.info, and The Silk Road are getting DDoSed; services like Instawallet and mining pools are having funds stolen; exchanges getting shutdown by regulators; (including Mt. Gox suddenly shutting down their off-chain payment service) even child porn related data being uploaded to the blockchain:

It is widely speculated, based on common forum comments in the crypto-anarchist community, that this current round of data spam is intended to force bitcoin users, developers and governments of the world to take action to censor -- or not -- certain bitcoin transactions.  Trying to force the issue, to establish a precedent one way or the other.  Or, more pessimistically, a party could be simply trying to shut down bitcoin.

-Jeff Garzik

The Bitcoin Foundation itself is in a difficult position: we all know who it's funded by, and everyone involved is publicly known. This can be a problem: in the last round of grant proposals at one point Gavin suggested someone submit a grant for a trust-free mixer service to help people make the coins in their wallet more anonymous by mixing them with a large pool of other users. I asked Gavin about that later, and he said the foundation lawyers nixed the idea because efforts to make Bitcoin users more anonymous could be seen to be aiding money laundering, especially if the foundation itself was paying for development and to run the servers.


We can work with regulators to make sure Bitcoin is acceptable to them. For instance we can ensure that it remains possible to track the flow of money through Bitcoin. We can also ensure that there are options if certain funds need to be frozen and blacklisted, due to fraud, theft, or because they encode illegal data. We can work with them to find ways to apply AML rules to Bitcoin transactions and to the exchanges. There are ways to put taxation into Bitcoin itself, so that taxes are automatically applied when a transaction is made. Maybe even one day we'll be required to prevent dangerous levels of deflation. A lot of these changes are technical, such as improving scalability so transactions can remain on the blockchain, developing P2P blacklist technologies, and preventing deflation.

We can also go the other route, and give Bitcoin users even more tools to remain anonymous and transact on their own terms. Technologies like mixing and off-chain transactions to let you make transactions without revealing where the coins came from, technologies like P2Pool to ensure mining stays decentralized, and colored coins to let us trade our assets without involving third party exchanges.

I think this discussion needs to happen out in the open, and we need to have it now. I'm sure you have a pretty good idea what I think, but what does the rest of the community think?

I thought I'd let everyone know about a project of mine that I've been thinking of doing for awhile now, but is finally actually happening. While much has been written about the blocksize issue on these forums, very little of the discussion has been presented in a nice, accessible way, like the we-use-coins 'What is Bitcoin?' video. So I wrote up a preliminary script, tested it out on some friends of mine ranging from non-Bitcoin users to fairly serious investors and tweaked it until it worked. I then got in touch with stonecanoe (run by former classmates of mine) and we should have a roughly 2.5 minute animated video done in time for the conference. I'm pretty happy with the cut-down script and we're working on nailing down the storyboard in another day or so, followed by about two weeks of production if everything goes well. I'm also working on material for a website to go with it, and in the process learning how little I know about web design.

Why am I doing this? It's simple: right now Bitcoin is democratic. The blocksize simply won't change unless we all agree to change it. On the other hand, if you can't run a full validating node, you aren't participating in that democracy, so once the limit is lifted there is no going back. Beyond some niche troll-infested forums like reddit and this one the issue just isn't getting the mindshare it deserves. It's telling that the Silk Road forums, which have about as much volume that Bitcointalk, don't have a single mention of the issue, yet a centralized Bitcoin and the regulation that follows is a direct threat to the anonymity Silk Road users depend on.

Beyond that Bitcoin is far more important than just some internet payment system. Sure, calling it one is a nice safe thing to tell authorities, especially when you remind them that every transaction is public and easily traceable, but what is truly unique about Bitcoin is that it's the first currency with democratic decision making baked directly in the technology behind it. Everyone with a full validating node is a part of that democratic process.

I don't want to see that democracy sacrificed just so people can buy songs and make penny bets over the internet.

Neither do the concerned investors who have given me the first $3k worth of donations to cover the cost of the video. Right now I'm on the hook for the rest of the $7k cost, (after taxes) but if you want to help out my donation address is in my sig. Having said that the project is going ahead regardless; the long-term viability of Bitcoin is something I truly believe in.

EDIT: As it turns out replace-by-fee will eventually allow for fairly safe zero-confirmation transactions, ironic really: https://bitcointalk.org/index.php?topic=251233.msg2669189#msg2669189


Someone by the name of John Dillon (john.dillon892@googlemail.com) emailed the bitcoin-development email list earlier this morning offering a $500USD reward to anyone who implements a transaction replacement-by-fee patch. That's an idea I posted on the email list two days ago:

In any case, the more pressing issue re: replacement is changing fees attached to transactions after they have been broadcast. Lots of users are getting their transactions stuck with few options to fix them.

The more I think about the issue the more I think we should nip this zero-conf madness in the bud: change the relay rules so that transactions are replaced based on fees regardless of how that changes transaction outputs. Of course, this does make double-spending an unconfirmed transaction trivial. On the other hand, this makes changing fees after the fact trivial, and it lets us implement a limited 'undo' button for when people screw up. It also allows for many of the applications transaction replacement was meant for in the first place anyway, and all the applications where it's actually secure.

We keep saying over and over again to stop accepting zero-conf transactions, but people do it anyway because it seems secure. It's a very dangerous situation because the security of zero-conf transactions can change overnight simply by some fraction of the hashing power implementing that exact change.

Some thought is required as to exactly what "replace by fees" looks like, economically optimal is a bit complex due to it's dependency on overall mempool backlog, but a rough first version should be easy to hammer out.

-Re: [Bitcoin-development] [bitcoin] Enable tx replacement on testnet. (#2516)

Like it or not, zero-conf is dangerous when you don't trust the other party. I wrote the above replace-by-fee idea because I really think we run a risk if we lull people into complacency. The blockchain and the proof-of-work system is how Bitcoin comes to a consensus about which transactions are or are not valid; trusting anything else is dangerous.

When you accept a zero-conf transaction the method of determining consensus basically comes down to hoping that all miners implement the default "no-replacement" rules, rules that can fail due to a bunch of other reasons like propagation failures. Mining pools these days are run by individuals as a (serious) hobby, and are usually hosted on insecure VPS services. The security of zero-conf transactions can change overnight by one of those pools getting hacked, or anyone with hashing power deciding to change the relay policy they use; about 10% of all blocks have unknown origins.

Trying to bolt on a second consensus mechanism, like nodes rejecting blocks if there are transactions in them that they haven't seen before, or conflict with existing transactions, is dangerous. That second consensus mechanism becomes a way to attack Bitcoin, and it can be as simple as just broadcasting different transactions to different miners so they don't know what transaction was first.

Full disclosure: I'm considering writing that patch and collecting that $1000 reward myself.

EDIT: reward has increased

Mike locked his original thread unfortunately, so I thought it would be good to continue the discussion about assurance contracts here. Specifically, how to make them work, as well as other possible mechanisms. Regardless of what happens with the blocksize it's important in the long term: without the block limit we can expect transaction fees to fall to the marginal costs of a transaction, which means the fees aren't paying for any security at all, on the other hand, with a small blocksize limit, as I've been arguing for, you still run the risk that off-chain transaction systems get 'too good' and so few transactions actually happen on-chain that security still isn't being paid for. Mitigating both issues is the fact that we've got until about 2033 until the inflation subsidy decreases to even 1% - if keeping Bitcoin secure costs a few % of the value of the Bitcoin market cap every year in the long run, maybe Bitcoin is just too expensive?

An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.[3]

The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. In Bitcoin the problem is that mining is costly and benefits everyone who owns Bitcoins and/or performs transactions. A mining assurance contract needs to be constructed in such a way that participants agree that if some large amount of funds are commited, those funds will go to mining in some way, with the amount set to be large enough for a sufficiently high percentage of the economic activity of Bitcoin must have participated to avoid the free rider problem.

Bitcoin already supports assurance contracts as a transaction type[4] - for a mining assurance contract the transaction output would be set to either an anyone can spend output, or an address owned by a specific miner. However as-is they have a serious problem: a miner can always collect the funds pledged to date by simply adding a sufficient amount of their own funds to the outstanding contract, and mining that transaction themselves, thus turning the contract into a simple donation.[5] (modulo the small chance of the block being orphaned; if the chance is large, the assurance contract is not encouraging orderly mining) The problem can be mitigated somewhat by forcing donators to reveal their identity in a provable way, but then high participation is difficult to achieve.

With nLockTime a transaction can be created where the miner who will actually collect it is unknown in advance. As the deadline approaches, if the contract is not fully funded, participants double-spend their pledged transaction outputs to invalidate the contract. However this mechanism has the problem that anyone can make the contract fail, even if it is fully funded. That problem can be solved if Bitcoin's scripting language is extended to allow for transaction outputs that can only be spent by transactions following certain forms - the outputs would be locked to the contract until some time after the contract expires.

Funding network security

I wrote the above in the Wiki, and I think with the nLockTime + transaction templates fixes it's a workable approach that truly acts as a proper assurance contract, so technically speaking I think the idea works. Economicly and socially? I'm not really sure - at that point implementing proof-of-stake or even just signatures on blocks by trusted third parties might happen instead. It's hard to know, but what's important is the option is there.

I also really like Gregory Maxwell's Transaction checkpoints:

Each transaction (or signature?) should contain a block index and 32 (?) least significant bits of the block hash. The transaction's fees are only valid (or only their full value?) if they are mined in a chain they agree with. This would let people making bitcoin transactions 'vote with their wallets' on the identity of the chain they consider important. This isn't a viable POW replacement, but would greatly reduce the economic benefit of mining moderate depth forks, esp as fees begin to dominate the block reward. "You don't get (all) of my fee payment if you are mining a chain I don't like!"

• Nodes would typical checkpoint a few blocks in the past from their current height to avoid overstating their opinion unnecessarily.
• Deep checkpoints could be automatically triggered by observing a critical mass of coins-day-destroyed confirming them— creating a PoS-ish system, though this is subject to the 'nothing at stake' problem of PoS, and is probably very dangerous. (e.g. isolation risk for newly bootsrapping nodes)

User:Gmaxwell/alt ideas

Essentially they're acting as a really fine-grained way of saying which version of Bitcoin history you support, and thus which version of Bitcoin history your transaction fees can go to. If the blockchain is re-orged deeply enough that the version of history now does not agree with what you agreed with, the miner who did that doesn't get your fees at all. He proposed it in the context of my Discourage fee sniping with nLockTime pull-request, it's essentially a much, much stronger version of it, albeit one that requires a hard-fork.

What's interesting is you can combine transaction checkpoints and assurance contracts to create a contract that miners can only collect if they follow the wishes of the people funding the contract. The way it would work is you would first commit some funds to a transaction that can only be spent by an assurance contract for some amount of time. Next you find a contract you agree with, including what transaction checkpoint the contract will have, and quickly (within 2-6 blocks) add your inputs to the contract transaction. If enough people commit, it goes through. If not, you can find another contract, or wait until your locked transaction ouput expire and send the money back to your wallet.

Now if the chain gets re-orged, the rules are that the new block can't collect the fees from the checkpointed transactions. Gregory Maxwell suggesting adding those fees to a pool given to all miners over time, but I think perhaps simpler, and easier to construct short proofs of, would be to just add a new rule that turns those fees into a transaction output that can be spent subject to some conditions. This could be done directly as a scriptPubKey/txout:

Code:

<32-bit partial block hash> IS_HASH_IN_CHAIN? IF <tx out goes to fees> ELSE <pubkey> OP_CHECKSIG ENDIF

The overhead here might be too much given a limited blocksize, and again I'm not sure that socially or economically the idea works, but technically speaking I think it's feasible. Thoughts? I'll add the transaction checkpoints stuff, with and without assurance contracts, to the Funding Network Security wiki page as yet another future possibility if the idea withstands scrutiny.

Trust free mixers have the problem that you need to trust the mixer to not reveal the participants, or conversely, trust the participants not to DoS attack the mix by failing to sign the transaction.

However, enter Distributed Hash Tables! Er, I mean fidelity bonds.

Each participant buys a chaum token with their bond, and then submits a txout they want to see in the next round of mixing. They also commit to a hash of the txins they promise to sign before the round deadline.

Now they reconnect to the mixer under a new identity (think tor circuits) and sign the transaction inputs. If everyone does sign the txins required before the end of the round, great! The tx is complete and can be sent out.

If anyone doesn't, not so great, however each participant can get their chaum totkens reissued back by revealing what txins they initially promised to sign. The person(s) who didn't meet the deadline lose their tokens.

Of course, it could be done as straight up fees as well, but with the bonds you could re-use the right to talk to the mixer over and over again - each txout can be associated with a new pubkey that gets the right to another chaum token.