It's generally considered a bad practice to use the same keys for signing and encrypting, though its not quite as much of a trap for ECC as it is with RSA. Although it is somewhat easy when making things that do ECDH like this to fail to validate that the nonce sent is a point on the curve, and by doing that pretty easily leak the private key.

Calling this a "PKI" is a stretch. If I had to give you an address, I could have just given you a public key instead... then the use of a centralized database or even the blockchain at all wouldn't be required (no normal bitcoin node keeps an index that would be useful for this lookup, nor will any by default because doing so would add a gigabyte-and-growing overhead).

As Luke mentioned, the authentication use-cases are better handled through regular signmessage. This has the added benefit of not needing to depend on the centeralized key resolution service since you can authenticate a signmessage with only the address, plus it's already deployed.

Cheers.

Well, I wouldn't have taken it because having a unit a month earlier would be worth the difference in price. But now it sounds like that won't be the case.

Though there really is no comparison to hashfast which cost twice again as much and is already several months late.

This is a common misunderstanding but it just isn't how expected return works. Consider a hypothetical case where there was only ever going to be one more block ever— sort of like difficulty going up infinitely.  Your expected return of one technique vs another still works out just fine.

Future blocks— and their difficulty, higher or lower— have absolutely nothing to do with what your expected return is in choosing to mine this way or that in this instant.  The possibility of getting less than what you deserve is counterbalanced out by the possibility of getting more than what you deserve and the sum of the possibilities is the expectation. Amusingly: the chances of being overpaid are greater than being underpaid (median of the exponential distribution is less than the mean).

...and people who've been mining on p2pool all year have made something like 12% more than they expected— due to that possibility of getting somewhat more than you deserve, and perhaps some inherent forwarding advantage of P2Pool due to its distributed announcement.

Regardless of the overall variance, what pooling primarily accomplishes is reduces the probability of getting _way_ less than you deserve for weeks at a time to negligible levels, and p2pool does that quite nicely and without undermining the security design of the Bitcoin system.

I think it's pretty easy to argue with that:  When the consolidation of hashpower at a party who is apparently willing to allow it to be used to rob others and profit undermines confidence in Bitcoin by basically disproving the security model— what are the coins you mine going to be worth?

I think this is a bad idea, and I pointed out that I thought it was a bad idea the last time it was proposed.

There is absolutely no way to prevent people using brainwallet from shooting themselves in the foot. What the reference software does is probably not even relevant in this case since it submits directly to bc.i and bc.i is directly connected to many miners (who, if they're not asleep at the switch will just remove the limit).  There are real applications for paying large fees, and any fee you select is at risk of becoming not-large or too-large at unknown times in the future.

You mean you are uneasy that he chose the _only_ standardized curve at the time without unexplained parameters?

"Just" as in >1500 blocks ago (IOW over a week ago)?   Current Bitcoin-qt codebase will not aid someone in footgunning like this, but there isn't anything we can do about irresponsible services like brainwallet (which create extreme risk of loss in several ways, not just this one).

Please don't start another thread about this.

Where is the pump in that setup?

I split off a bunch of OT hashfast stuff into https://bitcointalk.org/index.php?topic=372651.0

Sorry about that. Can you all please keep this thread on the subject of CoinTerra?  Some comparative mention of the competition is inevitable and fine, but if your messages are not PRIMARILY about CoinTerra thats not okay.

Excellent point!

As you note one workaround is don't reuse addresses— always good advice and here it doesn't have to be "phased out" in general but just by participants— but it's always better to be secure even if software is used dumbly.

I can suggest a trivial protocol addition that solves this without making the CJ transactions distinguishable or degrading privacy, but my solutions have some overhead. I'm curious if anyone can come up with a better way of doing it that doesn't have the overhead.

The general idea is that the merging party can just make a list (blindly) mapping their inputs to outputs, give the list to all players, and commit to the list so that all players know they got the same list.

Here is how it works:

The merging party makes a list with an entry for each output in the transaction. The entries have a nonce provided by each user either when they provide their input (or submitted their blindsigned tokens if blind signed tokens are in use). When they ask the users to sign they give the users the list and the users check and see that they are the credited party for every output they think they should be. Because they are just nonces they don't deanonymize users.

But to prevent the merging party from giving a different list to each user they must commit to it. I have two way to accomplish that:

The first is that we could require that a particular index in the outputs pay to an address which commits to the list: The merging party computes a new public key as an existing pubkey plus the H(list)*G, like a pay to contract, and a previously designated output pays to the resulting address. Given the list and original public key, everyone can check that that output commits to the same list. (And if two different users are given different lists, their signatures will not be merge-able since they would have signed different outputs).

(This designed output could belong to the merger or players could volunteer to have their output address placed in the designated position and to instead receive their payment at a pay-to-commit address. This is a little lame though, because it requires that there be at least one player that will tolerate receiving coins at a non-deterministic key.)

The second way to commit that I've come up with is to add an additional round to the protocol where you make a dummy transaction modified so that it won't ever be valid, e.g. using the list hash as an addition vin. Everyone signs this transaction and then only once they've seen this commitment signed by all the inputs will they sign the real transaction.

Needing an extra communications round or a non-deterministic output is kinda weak. Can better be done?

Why do you think I have any control over these things? I have the ability to delete, move, pin and lock threads, and edit posts in a couple subforums and to whitelist newbies— thats it. (though— at the same time, if I did, its far from clear to me that taking their money where it can be funneled to productive uses is a bad idea. Crappy businesses are going to exist regardless... and no one could hope to screen them all out in any case. Caveat emptor, etc.)

You're really going to mine at ghash.io? https://bitcointalk.org/index.php?topic=327767.0

I'm not sure what your issue is there. Low hash-rate miners won't be paid in every single block— once their rate is low enough that they don't constantly have a share in the window, but when they do get paid you'll be "overpaid" and as a result there returns will be as expected on average.

It doesn't return connected peers at all, it returns some peers that it knows about. Connected is orthogonal.

Maintaining the expander graph property and protecting the network against accidental partitioning and the randomness property which makes adaptive attacks not have big sibyl advantages are far more important that propagation speed. Generally proving any particular optimization can't be misused— or even won't just naturally partition on its own is quite tricky.

Anyone have a citation for the offer to convert to January orders? (I assume it's burred in this thread someplace?)

[Edit: Ah. They got ahold of me. I'm all good now.]

leaks are one of the potential problem with watercooled systems. I guess it's fortunate that their demo unit leaked in shipping, since it will increase the visibility of the risk of the problem for them.

FWIW, HF's prices for the first batch were almost exactly 2x higher than cointerra per hashrate— a fact that was perfectly reasonable because they were talking about OCTOBER SHIPPING, and sure yea, delays happen, but it now seems apparent that they had no intention of ever meeting that advertised target I can't imagine any of the first batch customers would have bought HF instead of CT had they known the truth.

I don't think I knew about the offer, thought I likely wouldn't have taken it in any case.

My email shows a 10% off coupon for a January order, which I didn't opt into as I didn't think doubling down into an unproven hardware company would have been wise. The boards and cases look pretty nice. I'm looking forward to receiving one.

Without HS support the Bitcoin network cannot operate on just Tor alone, it requires IPv4 Bitcoin nodes to be healthy, available, and uncensored. With HS support Bitcoin can run entirely within Tor.  HS support also allows nodes behind tor to add listening capacity to the network, otherwise all you can do is consume the listening capacity provided by others.

As a result, contrary to claims in this thread, HS' do reduce sibyl attack risks: The additional connections you get from being a HS supporting are additive, and so they can never reduce your security against isolation. Without inbound connections a node only runs outbound sockets, so it consume the inbound socket capacity of the network without giving back to it, so the number of connections which nodes can sustainably make out is limited. Accepting HS connections inbound allows you to sustainably have many more connections, increasing the chance of being connected to the honest network even if most are sybils.

Tor's default selection of exit circuits also causes exit clustering which can reduce privacy— you'll connect to Bitcoin peers (potentially _all_ your Bitcoin peers) through the same circuit you use to browse web pages, which can create linkages visible to exits which deanonymize you. This can be avoided in a number of ways, but it's avoided completely simply by using hidden services.

Finally, the Tor network is often strapped for exit bandwidth. Interior bandwidth is generally much more plentiful. HS' have higher latency but often achieve much higher throughput— a reasonable match for most Bitcoin usage.

Thats it, — no yadda yadda about illegal crap. Bitcoin's HS support makes Bitcoin over tor more privacy, more scalable, and less brittle.

What you should have said is "Bitcoin OMG is just backporting patches from Bitcoin 0.9, I'm not actually writing these things." because it seems some people think otherwise!