On this general subject, I've been enjoying Peter Todd's dust-b-gone: https://github.com/petertodd/dust-b-gone/

It works with Bitcoin-qt / bitcoind and scans your wallet for tiny coins and signs them off to be joined away... both thwarting dust payment deanonymization attempts and defragmenting your wallet a bit.  I wish Peter would do the last bit of effort to figure out how to produce a windows binary like p2pool has to make it easier for people to use.

(I've audited it and test it, and I consider it perfectly safe to use as of the current version)

"brainwallets" far more elaborate than those (e.g. ones with 60+ character inputs) have been compromised. Humans are not an acceptable source of randomness.

If the salt is large enough to provide adequate security you can just use the password to encrypt the salt instead, and then you don't have the key management nightmare of a password which can never really be changed.

Last I checked they were cryptographically locked to BFL's FPGA images and BFL won't provide the info needed to reprogram them. IIRC they also can't be reprogramed over the USB bus.

Yea! If I make a BTC3 that removes all the inflationary limits and transfers everyone's private keys to me and does whatever else I like then this forum has NO RIGHT to prevent me from posting all over it telling people to use it!  DOWN WITH CENSORSHIP.

Great.  Sorry for my confusion, I missed that it was referring to the blog post and instead though it was referring to the post shortly before on the forum.

As far as I know, they wern't. They're just comments posted to the public blockchain.info website. Because of the unfortunate naming of that service the media (and many Bitcoin users) mistake it for a formal part of the Bitcoin system.

If it has a sufficiently complete one. Last I checked cgminer's implementation couldn't be used for solo mining but bfgminer could.

They're not even getwork they're kind of a bastard half implementation of getwork that does things like ignores difficulty and spams results. You really need to use them with some kind of proxy. I believe bfgminer can be used as a proxy for them.

Ah, you're trying to getwork mine against bitcoin-qt? With an asic miner? Crazy.  Getwork is depricated.

We support getblocktemplate in bitcoind. This is how you should be solo mining against it.

(And yea, vardiff wouldn't make any sense for solo mining. It would only be useful for stats collection, and bitcoind does no stats collection for mining)

No. It is not indicating any insecurity in any meaningful sense. It basically says that if an attacker captures your kernel internal random number state (how?) and then controls the input into the RNG (how?) the problems with the entropy estimator can make the output remain deterministic to them.

It's interesting from a cryptography perspective, but they are not suggesting that this is a weakness which matters in any normal application.

(It's also worth pointing out that their suggested "fix" is to replace /dev/random with what is fairly similar to AES-GCM with the galois counter perturbed by input randomness. Considering people's violently negative response to Intel's bull mountain AES based rng, I can't see something like their proposal being adopted anytime soon)

The node may not even have that data at all.  It's not an inconsistency. The scriptpubkey in the spent transaction required you to satisfy certain rules, and the transaction did.

You can have a trivial protocol for multisignature assignment with an anti-replay oracle.

An anti-replay oracle is just some dumb trusted program which signs anything anyone gives it, with a constraint that it only signs once (or a finite number of times) for a given key.

You write a transaction sending your coin to a multisig You+Anti-replay-oracle, you ask the oracle to write you a refund nlocked to some expiration time in the future.

The oracle signs, and then you announce the payment into the escrow.

After that confirms you can pay people from the escrow instantly and they can trust that you will not double spend them before the published expiration time so long as they trust the anti-replay oracle to behave faithfully.

There are many ways to address these cases... just requires some UI innovation to make good software to make it practically usable for people.

There is nothing in the scheme that we use which can be generically described as a seed either.  Our curve meets the SafeCurves definition of "Fully Rigid" (as I explained to you elsewhere by comparison to curve25519).

Edits:
It isn't:

I specifically addressed your transparency FUD when you were spewing it elsewhere on the forum:

As an aside: I've now removed AnonyMint from this thread. (Also, note that he edited the message after I responded to it, my quote is the version at the time I responded)

Their rigidity page doesn't appear to explain the choice of generator for any of their "Fully rigid" cases.  See upthread that it would be preferable for the generator to be rigid too, if not essential.

This device is not the same class of device that computer scientists are speaking about when they say "quantum computer". It's analogous to building a digital computer that can only perform addition: An add-only-machine "computes", but it's not turing complete. The DWAVE devices are not quantum turing complete: they cannot perform the fast quantum period finding algorithms which would are apparently needed to recover a private key from a public key. It is a quantum computer only in the sense that it computes and (maybe) uses some quantum effect. Nor does their device appear to have any clear way to generalize to quantum turing completeness in the future, nor are they claiming that it does.

Moreover, you asked for an even harder problem: Converting an address to its private key requires finding the pre-image to RIPEMD160+SHA256 (and its discrete log), and this wouldn't be efficiently computable on a real quantum computer.

The noospheer guy has been all over the place trying to collect money for his batshit craziness. He emits a lot of technobabble that doesn't have any credibility. If he actually could do what he claims he could trivially prove it to anyone (e.g. by finding a discrete log of a nothing-up-my-sleeve point).

People frequently exaggerate the capabilities of quantum computers. Indeed, such a device would be magical and a breakthrough and would help solve many interesting problems. But quantum computers are not even conjectured to break _all_ encryption, they only break some classes of cryptography (such as asymmetric cryptography based on the hardness of hidden subgroup problem in abelian groups, like factoring and discrete log), and even then only if the QC is sufficiently large (in terms of gates and coherence length).

You are specifying your value as a string.

The results from the scriptSig are already on the stack when the scriptPubKey executes. So the signing party is providing the pubkey, and thats whats getting duplicated by that OP_DUP.

I can't actually figure out what you're asking about. Can you try again with some more context, especially please describe what you're trying to accomplish.

Easiest?  Press the +add destination button in Bitcoin-QT and type in the additional destination.

One gigabyte (assuming that security level, it was a random number) per peer that they are using a storage proof to get priority access to. So they don't necessarily need to have one per outbound peer.  The idea would be the your peers would prioritize inbound connections that were providing a storage proof, everyone else's connectivity would depend on other criteria.

There is no "their own" storage requirement the whole basis of this idea is to be memorless on the server.

Node could pick their favorite couple peers to use storage proofs on, and if they get bumped off other peers during a dos attack, it's not the end of the world.

The problem there is that an attacker could just slowly build up proof free connections to the whole network and still saturate things.

Long term I expect our behavior with inbound connections to look something like:  When a new connection comes in and we're full, randomly drop a peer (including, possibly, the new one) based on a priority scheme.  The priority scheme could reserve a number of slots for each of several different kinds of priority.  For example, some slots should be reserved for the longest connected nodes— since having a long uptime connection is a kind of scarce resource and some attackers come in bursts.  Other slots should be reserved for peers which have the lowest minimum round trip time (because being close to you on the network can't be faked), come from the same subnet as you, come from many distinct subnets, are often the first to relay you new blocks, have an IP that when hashed with a secret is a low value, etc.  You can list out a bunch of different groups to protect... then randomly (weighed by goodness or whatever) kick nodes that don't make the cut.

One problem with that kind of litany of criteria is that you'll still end up with clients that just don't meet any of the protected classes— they won't appear to be highly useful good nodes, because they're not highly useful (esp SPV clients). They may not be near any of their peers on the network, they may be freshly started and so have low uptime.  So it would be good to have a way for nodes to opt into priority without creating an easy avenue for attackers.... thus ideas like a proof of storage.

Motivation:
Consider a mutually distrusting decentralized network where each node has some finite capacity, like Bitcoin's P2P network, with 100,000 nodes.

An attacker wants to soak up all the connection capacity of the all the nodes in order to funnel new peers to malicious nodes the attacker controls.  Each node can perform actions to make resource usage costly. For example, each node could reject additional connections from single IPs or subnets, requiring the attacker to have access to more address space (a scarce resource) in order to use up that nodes' capacity. Or they could prioritize peers that present a costly Bitcoin bond (e.g. a Fidelity bond/SIN).

The problem there is that the attackers effectiveness scales with the number of victims— e.g. each IP or bond or whatever lets them use 100k sockets—, since the nodes are mutually distrusting and thus can't collaborate to reject an attacker who makes one connection per IP to every single node in the network.

The network could respond by requiring a scarce resource to connect— e.g. a POW or a Bitcoin fee. But an on-connect fee doesn't really map well to a ongoing resource utilization.  You could require a periodic fee (e.g. intermittent POW), but setting the rates so that it doesn't favor attackers (e.g. an attacker might not mind spending a half bitcoin to attack the whole network, but regular users might not tolerate a 0.0001/per connect cost).

Also, most POW schemes are subject to huge speedups by more efficient implementations. E.g. a FPGA or even GPU implementation will be enormously faster than a java one used in most clients.  A memory hard function may narrow the gap, but common memory hard functions are just as memory hard to validate as they are to produce (though it's possible to do otherwise), and increasing the server's resource utilization is not a great way to address a resource exhaustion attack.

What might be useful is a POW function which maps well to the kind of resource usage that holding a connection represents and is also less vulnerable to speedup for specialized attackers.

One idea that has been suggested for this would be to have a storage hard function: Some function that forces you to store a bunch of data and continue to prove you're still storing it while the connection is up.  Making one that is storage hard for the client but not the server seemed pretty tricky and eluded a number of people for some time. I had a prior idea, which required fully homorphic encryption to create a sequential function with a trap-door property to allow random access... which might have worked but it was so complicated that no one would ever bother with it. Fortunately I've since had a better idea:

A proof of storage system:

Take some fast cryptographically strong pseudorandom function, e.g. like Blake2 or another hash function H().

The server gives the client a random seed and a target size. The client repeatedly applies H() in a tree, e.g.  {Left, Right} = H(seed) and so on, to build up the target size worth of data.  The client takes the final leaves of this tree-structured pseudo-random function and appends their index and sorts the data (or, equivalently, stores it in a binary search tree).

The server then can periodically pick a random index and perform log2(size) hash operations to determine the value at that index and then can challenge the client to provide the corresponding index for that value.

The tree structuring of the function means that you can cheaply lookup the value for a given index,  but looking up the index for a given value requires computing the whole thing (and storing it, if you want to efficiently perform multiple lookups).

(There are some possible optimizations in the client, like common prefix compression, but they're only small optimizations because the function is strongly pseudorandom)

A gigabyte table wouldn't be too insanely burdensome for many kinds of clients, but would require a terabyte for an attacker to use resources on 1000 nodes. Such a scheme could be offered optionally to clients (e.g. if you perform a storage proof you get a preferred connection slot) and so it might provide some value in making some attacks ineffective.