You do not need the public key to verify the signature. The address, signature, and message are sufficient.

Yea, but who cares if they "keep" payments of 1 satoshi? Even thousands of them add up to nothing.

The advantage of coinjoining them up and giving them to miners, as Peter's tool does, is that it also thwarts attempts to reduce privacy (paying exhausted addresses tiny amounts in order to produce extra linkage)... and giving the coin to miners is the most incentive possible for miners to accept the transaction (short of actually paying extra to get it mined).

It's probably not something you'd want to use for "dust" at the scale of 0.01 BTC to (say) 0.0001 BTC. I posted a tool (now probably bitrotted) for general defragmenting last year:  https://people.xiph.org/~greg/groomer.py  basically it aggregates up outputs while trying to avoid reducing your privacy.

It might be interesting to combine the ideas in peter's tool:  For very tiny coins, give them away to miners, for larger ones aggregate them up and return them to yourself.

They may, BC.i runs nodes that do this. I've seen other aggressive connectors in the past, and surveillance is one of the possible explanations for them but for most of them it's impossible to know for sure.

There are more benign explanations though. For example, some people erroneously believe that connecting to large numbers of nodes is in their interest— e.g. they're miners and they think it will improve their block propagation, in fact because the relaying is sequential it generally tends to hurt your block propagation to do this... and they go around addnode=ing hundreds of nodes.

I've spent a fair amount of time trying to figure out how the network can discourage this kind of behavior and don't have any great general solutions.  So far the best I can do is prevent mass-connectors from DOSing the whole network. For anti-spying the best I can suggest right now is moving your nodes behind tor.

FWIW, these are also the same nodes which have been triggering the incorrect time warnings.

That should get a new thread, if retep has time to follow up on it. Thanks. (I will be deleting my post once it's not needed to keep this thread from going offtopic)

Indeed, the provider of the public key used it the chameleon hash could be entirely independent of the parties making the transaction.  I don't doubt that it would even be possible to construct a threshold chameleon hash, where some N of M parties were required.

Thank you for the excellent explanation too.

One thing that I'd like to add is that the methods of crypto-anarchy are still useful in the context of a society which is largely politically dissimilar. For example, some contracts people form are _too low value_ to effectively use the kinds of tools to ensure honest dealing in wider western societies today (e.g. courts) or the easy centralized alternatives facilitate rent seeking (e.g. having to pay to use a game server in order to play a game with your friends, you all have network access and powerful computers, what do you need the server for?).  If mathematical tools exist that allow cheat proof interacting they are often inherently scalable— we can apply them to high value things and low value things alike, because once they're coded they're nearly free.

Having good tools at our disposal allow societies to pick appropriate tools for appropriate situations, and we can all only benefit from that.

Welp, better go fix this centralization then... it has a lot more costs and risks for Bitcoin than just SINs.

Weird. I thought I heard you using it as an example at the conference as a scheme which made a long term uncertainty of when you'd be paid.

I think it's something of an extreme example of making tradeoff for the lowest long term uncertainty in exchange for the higher medium term uncertainty. Kind of an odd example.  Primary argument I have against it is that the high medium term uncertainty kinda stinks.

IIRC the graph number minus DOA, but you get some of the DOA back because everyone else has them too. Should check with forrestv, also note you are 110% efficiency in that p2pool output, meaning you're outperforming the pool on average latency wise and are expect to get 110% of what you would expect based on your hashrate.

Is the CGminer claimed hashrate lower with p2pool then elsewhere?  If so, something about the hardware design / firmware / or miner driver is brain damaged.

Sure it can be and very likely is, but indeed, it's higher variance for tiny miners. I don't begrudge you your variance preferences, but please don't confuse your emotional response to high variance for sudden expertise in the system.

You actually can't. You need to use a proxy.  Otherwise the broken blade firmware will flood the pool with invalid getwork responses because it ignores the target difficulty. Some pools will ban you for this, perhaps most won't but it's still flooding them with bogus work.

The asicminer firmware is broken in a lot of ways.  It's workable, but not good. ... and you can still use it with P2Pool, you just need to tell p2pool that this POS is going to return difficulty 1 no matter what.

I'm unhappy with the subject line describing this as "hack proof", it's strictly weaker than other similar systems. (E.g. what electrum does)

In theory SINs could be blinded too:

You write a small program that takes in a SIN SPV fragment, a site name, a minimum sin value, and the private key for the sin. It verifies the SPV fragment, then uses deterministic DSA to sign the sitename and computes then returns {sitename, minimum sin value, H(txid || signature)}.

You run this problem inside a zero-knoweldge proof-of-knoweldge environment and the result is a unique ID per site which proves that there exists a sin of at least the stated value, but no information about which transaction is the SIN.

(The actual implementation of this is annoyingly complex, but we should try to nag the people working in this space to use it as an example application since it's probably the simplest use of these kinds of proofs which would have a big practical value to us)

Practically every block has free transactions, the blockchain disagrees with you.

Man, I'm certainly glad to not live in Sweden!
This doesn't achieve the goal. We want Alice to be able to prove to the world that bob is behaving in an untrustworthy way, but we do not want Alice or Bob to be more vulnerable to being coerced into making their private arrangements proven to the public than they would be otherwise. I don't think it's too much to ask that when we adopt a security measure to protect against one thing that we not become weaker against different attacks.

Under the scheme presented here after Alice and Bob are thoroughly happy that things are settled, if they are concerned about coercion risk they could even publish the chameleon hash key... then anyone could produce a fake invoice and thus the pay-to-contract would no longer be persuasive of the specifics of their arrangement.

In that case, even if you lived in a place with terrible inhumane people who would punish you for acting to save your life against a threat of immediate death you still wouldn't have to have been the person to have made a forged contract.

If Bob is known exclusively via his point— e.g. Bob is a well known trader who's activity is associated with that point, you're done.  Alice can show that what she paid to was contract + Bob's point.  Otherwise, you need PKI.

You should not be reusing addresses. If you want memoriable addresses, use a https URL that issues a bitcoin payment URL in response to loading it.

Then what you are saying makes no sense. If an unsigned receipt is valid then why would a signed receipt be invalid just because a CA was compromised?

uhhh.  So you're saying that every receipt that doesn't have a cryptographic signature on it (meaning basically every receipt which has ever been created in the history of mankind) is "invalid"?

The CA model is weak and lame and mildly exploitative. But what alternative are you suggesting?   This is an optional feature, and if it's used its certainly no worse than if its not used.

The protocol itself is specifically designed to be extensible to other authentication types, but at the moment there don't appear to be any actually useful alternatives, as they arise future extensions can add support for them... and you still have the option of not using the authentication.

Or what the terms of the agreement were.  "It was a donation!"

And forget courts— though perhaps someday it might matter in those too— it's also about making the case in the court of public opinion. Certainly plenty of people have made fraudulent scam complaints (against business competitors or just for fun), strong evidence for a contract protects both parties and the public in general.

Making strong cryptographic evidence of contracts is an important part of building infrastructure that enables people to freely contract without depending on things like courts to enforce their agreements. Less use of trust and subjective calls and more use of math.