Anon136, there is no need to reduce the set of facilitators in any way, even by distributed consensus. But miners could certainly publish lists of perceived reliable facilitators in their blocks, helping others to find them. There's a proposal along these lines for peer lists that is currently circulating the development mailing list.

Really? Because to me that seems totally out of left field.

Adam, I don't think that's the issue. The air-gapped communication is just an interesting tidbit about how it operates (presumably to mesh network inside of secure facilities like Iran's nuclear research bunkers). Presumably BadBIOS is state sponsored, and not concerned with bitcoin. But hypothetically if it were a wallet-stealing malware it has perpetual root access to the machine it has infected and be able to scan RAM or disk for bitcoin-like data structures and steal the private key as it is scanned or decrypted in memory. By residing in embedded peripherals it is able to inject itself first into the BIOS/EFI, and then into the OS kernel during the boot process, and cannot be removed by any existing generation of anti-virus tools or user action (solution: buy a new computer and think up a creative way to get needed data off the old without infecting the new).

That's why you use multiple facilitators, and act as act as facilitator yourself 1/N of the time. The implementation I'm working on is fully p2p.

It is, and this is exactly what badbios is about. The target is not the OS's USB software stack, it's the USB microcontroller itself. It then spreads to the keyboard. Or the sound card's DSP. Or the CPU itself (yes, there are multiple microcontrollers inside the CPU). All of these devices have direct access to the machine, circumventing any OS protections.

dacoinminster, if badbios does what people are claiming it does, you're fcked no matter what. There's nothing a user-level program like Armory can do to protect you, except perhaps using a TPM chip. There are no robust wallet apps with TPM signers that I'm aware of*, although this would be a good addition to Armory...

(* except maybe this?)

One way to do this is to put OP_RETURN in front of any scriptPubKey. That will not just make it unspendable, but also remove it from the UTXO set, and the off-chain convention would be simple: drop the OP_RETURN code, and then treat it like a normal script.

Given the recent rise in price, 85btc is a bit excessive. I have lowered the crowd-fund goal to 55btc. If anyone is interested in donating but has questions/reservations, please don't hesitate to contact me in this thread or via PM.

Depends on which implementation you are talking about. In gmaxwell's protocol and my crowd-fund proposal, outputs are blinded so neither the facilitator nor any of the participants know which outputs belong to any of the others. So the facilitator doesn't have to be trusted, other than to complete the protocol. Genjix's server doesn't use blind signing & anonymous revelation, so I'd imagine you'd be able to trace ownership from the facilitator's logs (I haven't looked at his code, however).

It's also a very innocuous way to smuggle keys, using a pre-'shuffled' deck. See also: solitaire encryption algorithm.

Shuffle a single deck of cards very well. Write out the ordering using whatever scheme works for you, and hash256(). Repeat if you are unsure about the quality of your shuffle. (1 perfectly shuffled deck of cards is approximately 225 bits of entropy.)

Wow, that was very kind and unexpected. Thank you! I forwarded those coins into a cold-storage wallet that will be the start of her education endowment. Hopefully 20 years of deflation will turn it into a sizable chunk of her college education, and maybe even the start of a nest egg.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Education endowment for maaku's daughter:
1Naginiq19q9fdeFLipqFr4TZjjsSdhT3B
-----BEGIN PGP SIGNATURE-----

iQIcBAEBAgAGBQJSbiBOAAoJECsa1YSJj/UD6z4P/3jawSFnpMNt89elZmsm3OaJ
q2GMvC++X8+Y7n/RI5mN7Ubg4E2YLyGS6Xrf5f7mHBMq5FjW5UPL2GV0JDHEN+ni
ILQMvvNhI28Dj1rlZY2KdAYj6WUf50gVFY3Tv3hq3JZHEnoS2r2YPZ4dPH9Ls4zM
i6iQ/LJNs7hZFEiO+EDsPThjepFmRzpaBqi2mpW4BCnFl1gqYJiFUgSKrY2G8YYI
Eqh9Xq1rQft+utYY2gNuc8XtqrscmFmr5dHrWnqPe0cFPWrpG0HqY5QftaqfjMXg
WWZHuTPwul+QVwXOeimoPjdJ9gCi7sXyCZTa9MxvJ5n1QS/ubuHWKx5jUzbSx6m+
iFb+IX+tLYxcOecxfmftM645LQ8WlCJeY0p+EoskNpkdH4q63Sk1Nyq9dJMuQK+2
+MaFbB0Pv3AMk/Qoi/qrCF9F1BVD/CYK72uI8t+7r8iDvQ97iK5lGfLvCxR89Ev3
X3uCiJOpUctMozELjI7w3ga3xRah6mufKU2HgNRqkZAaphp7Cf5v34NwnSeaf9LM
A2tdBo8N86NVpjeyLz5U8TRnSrUcPDQPR4snz+IYF1sCKsRqYz9rNy1WhaIO7j6x
2A6nTnzvLUnenYLusu4hAIJ5XAlQMiGDL6sdALL2Z3or7mlx3IPz5elvn2FRd1fh
xkvdfNXeOkmrFd4x6m6h
=fzcm
-----END PGP SIGNATURE-----

There was a gap in funding in late September, and then I went incommunicado for a few weeks, because of this:



Now that we're back home and settled, I'm back to working on authentication trees. Thanks in large part to the generous donation of Armory Technologies, Inc. and a few others, and the recent rise in price, I have the ability to focus on this project for some more months.

Right now I am translating the Python code into a C++ libauthtree implementation, and working on a series of BIPs that describe the trie structure, various generic operations on it, and the specific application to txid indices, address indices, and merged mining. Invictus Innovations is helping with the BIP process due to their interested in using the structure for merged mining headers.

I will be consolidating the recent news into a blog post update soon, hopefully by the end of the week.

This is for cases where the number of future transactions is unknown, and perhaps unbounded.

I think you're confused. An “off-line” tumbler would still have taint from all the people who use it. As for swapping private keys.. I see no way to do that safely without hitting the block chain.

In the forum case, you'd probably need a special protocol, appending the username or database UID of the forum user to the path to get an address sequence for that particular user, which could then operate as a sequence with a small lookahead.

I had assumed what @justusranvier described was/will be the convention for HD wallet applications. Senders use the first address not in the block chain, and receivers look ahead a small number of addresses (if nothing else to guard against reorgs and race conditions). Of course there are other subtle issues, such as if the UTXO set only is used by the sender to see which nonce is used, then spent addresses will be reused. But as a convention, and until the payment protocol is augmented to support HD sequences, it's a good start. Should this be part of BIP 32?

Yes, we think. Any such proof would depend on the properties of ripemd160(sha256), which are not themselves proven. But that's a mostly academic point.

If ripemd160 works the way we think it does, every possible address has many, many private keys. The fortunate snag is that it would take longer than the lifetime of the universe to find one, if you started looking with today's technology (no quantum computer, no computronium the size of galaxies, no violations of the laws of thermodynamics, etc.). So what you're really asking is, how many (used?) addresses are there where the private (or public) key is not known? That's merely a reflection of our state of knowledge, and therefore a much less interesting question.

The utility of freicoin is completely decoupled from its price. I would not expect correlation.

HD wallets?