Arguably the reduction in 1 block commitment security might have useful benefits in security practices.

I've wondered before if some kind of chameleon hash couldn't be used for anti-censorship.  E.g. miner thinks he's mining transaction A but no no no there really exists a transaction B that he equally mined... but I've never found a way to make it work. Maybe I should think about using a proof of knoweldge.

I guess the biggest problems I can see with your idea are that:

(1) No one currently cares.  Pools, for example, can rob their miners undetectably... they _could_ do things to prove that they were not cheating, but none do.  Miners could use P2Pool which can't rob miners, but most do not. I imagine the story will be the same for cloud mining services, and they'll be able to use even more arguments about reputation and such to claim their honesty.

(2) The standard Mike Hearn argument: Part of the reason that Bitcoin is viable is that its very comprehensible (at least in broad strokes, if not for the subtle details) to basically any technically minded person, invoking some kind of zero knoweldge thing to _enable_ a specific kind of cheating is far more complex than anything currently in Bitcoin, even if it is a neat idea.

I guess the counter argument to (2) is that a lot of people initially believe its possible for miners (e.g. mining in a pool) to steal work, and it takes some effort to convince them that they can't.  Your idea would, in some ways, make mining more intuitive. I suspect its not possible to avoid breaking pooling, even in its most harmless forms, since anything that preserved pooling for payment would by definition be proving that the right parties were getting paid.

A maximum sequence alert can be sent which will override all other alerts and will display a static prefabricated message:

"URGENT: Alert key compromised, upgrade required"

This won't work. Everyone looks at diffs. Making the change in something that changes all the time would be a better strategy. In GIT it is not possible to make invisible changes either, and rewriting the history will make all git clients refuse to pull until forced.

If the system is vulnerable to this, then you can remove the third party "attacker" from the equation: One of the developers could just do this if it were possible.  Hopefully, enough people are auditing all changes that this wouldn't be possible.


About 1% check. But users update very slowly and we intentionally do not have a forced auto-update. And there are people running automated signature tests who would quickly notice a problem.


Certainly it would be possible, few things are not possible.  It's less clear that there would be a large amount of funds taken this way...

It's quite easy to test the retry, simply change the comparison criteria. To do less creates a certificational weakness which reduces the signature security below 128 bits. The level of testing required to adequately address isn't substantial compared to _everything else_ about the process, as there are many other mistakes you could make which would readily leak the private key but leave the software apparently working correctly.

Not for our G.

It should be possible, with an expensive search (e.g. >2^32 tries), to find a G that results in a lower hamming weight in the multiplies in a particular implementation and get a very small speed improvement. But I can find nothing about our G that suggests such a thing was done.

This will be changed to the alternative I described.

To prevent third parties from changing your txids out from under you and invalidating transactions spending your unconfirmed transactions by replacing S with the alternative value which also allows the signature to pass.  This malleability can be used to create enormous nuisances for Bitcoin users, causing stuck transactions and making innocent people look like malicious double-spenders, as well as can be abused to extort people in some escrow protocols.

See the second half of: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02721.html

There are multiple ways to remove this 1-bit of freedom. One way is to make S even. Another way, now used by bitcoin-qt git, is to make s < order/2. The advantage of this way of removing the vs others freedom is that it also reduces the average signature size slightly.  I now prefer the s < order/2 version of this just because it produces smaller signatures and the flip is even easier to implement than the even/odd version.

Please read the last line of my above post.

If Gavin was interested in (/thought his time was best spent on) those other things he would spent them on them. You can't dictate how Gavin spends his time by creating a fork.

As an aside, though the code ends up in the same binary, as I recall the payment protocol didn't touch consensus mechanism stuff, it was largely self contained and nowhere near the core stuff. Increased modularity is a long term goal to making review easier, though it's currently come a long way from the original code that freely intermixed the GUI wallet stuff with the consensus code.

Sorry, starbucks was run by Bernie Madoff and won't return your money. Basically under your scheme: Once you've given them the secret key for the refund they can say "HA HA, mine now!", and even without you giving them the key they can freely extort you ("Give us the key, or we're not talking. Maybe if you give it to us we'll give you back 10%") with no finical loss.

The escrow/timelock version can give you your coins back immediately if the vendor is cooperating too. The timelocked refund is just there to prevent extortion like "No, sorry, I won't refund your coins unless you give me at least half." or to deal with the vendor getting hit by a bus.

Certainly there are cases where you reasonably can trust the vendor, but in most of those you can probably go all the way to a premature payment and dispense with the split key stuff.

Locking thread because it's both run its course and they've actually got hardware in people's hands now!

Wouldn't this increase the amount of software which must be reviewed, tested, patched, and otherwise maintained? Is this just for the sake of removing parts which are largely inactive and harmless when not used?

I often don't understand proposals stated in terms of mechanisms rather than goals. Perhaps the benefits are apparent to those who would want it, but for my sake what benefit(s) would this serve which would justify the costs?

There is already have code to turn off the wallet. If there is a real application for turning off other things I don't see a reason that a fork would be required.

You are wrong. But you're asking in the wrong place— go see the nice article on wikipedia.

Page 10 of the complaint claims the site had a section listing hitmen. Is this true??  I thought the site refused to list guns and such... just consensual transactions. Whats the scoop?

...

1 : 29896722852569046015560700294576055776214335159245303116488692907525646231534  is a point on our curve, as is
2 : 46580984542418694471253469931035885126779956971428003686700937153791839982430

and so on. The first missing x, other than zero obviously, is 5.

Mining testnet is a very similar workload to mining shares on a pool. If you were saying you wanted to see a solved high difficulty block— that would be another matter. A technically superior test would be to mine recently completed mainnet blocks to verify that the device would actually submit solutions.  As it'll be quite awesome when, intentionally or otherwise, some mining asic has a "bug" that causes it to lose some percentage of its full solutions but not its shares... widespread deployment of such a device would probably put every pool out of business in a few days.

[Aside: I'm only bothering to reply to this thread because it's currently on top]

How about _any_ released version, including the most current one? (though the procedure you gave there is needlessly complicated in any case)

Though I wonder why you are displeased  with Bitcoin being build-able in the same way as virtually every other open source unix package for the past twenty years:


and instead prefer your six step process (which doesn't even suffice for building on many systems).

These are all really basic questions which have been asked and answered here many times before... some of them have their own sections in the original Bitcoin whitepaper. Please search for a bit before creating a new thread asking the same things over again.