Miners can change signatures, but obviously if they break the rules, their block will still be invalid. An extra signature that isn't needed to verify the transaction can therefore safely be stripped.

They'd need to be very smart to find all the safety checks in place

At least nobody can lose their past week's worth of earnings.

The key problem with "green addresses" is that it encourages service providers to spam the blockchain with moves of funds to a single address. Since these same services cannot have users send directly to the "green address", the need for an extra transaction/input to move funds to one is almost always needed.

On the other hand, it's possible to simply add an extra signature to transactions, signed by the "green address", which gets relayed with it. Service providers can check for this signature. Miners can (but don't currently) omit this signature from blocks, so it doesn't cause permanent bloat.

Since it seems a lot of pools have been hacked (and balances emptied) recently, I just thought I'd let everyone know that Eligius should be immune to this attack. Since we generally payout in generation, I can safely encrypt the pool wallet, and never unlock it on the actual pool server (ie, only create manual payout transactions on an offline system).

NMC uses SMPPS just like BC. The non-merged-miners are simply omitted from the algorithm entirely, which basically leaves an infinite buffer. Ergo, miners who have signed up for namecoins receive full PPS even when they would otherwise have received less due to the extra credit mode. This is especially important since we don't longpoll for Namecoin, and therefore, the stale rate is rather high - so unlike the BC side which has up till recently had a large buffer, Namecoin mining would simply have infinite growth of extra credit. My "share" is basically what I feel is comfortably not needed by the Namecoin buffer to pay miners during long "dry periods". The miners' "shares" are basically Eligius effectively paying for (a high rate of) stales.

Just thought I should note this post was written by Gavin himself...
If he doesn't consider himself to be qualified for the job, it's IMO quite silly to argue over it.

FWIW, I am also not qualified for this.

Gavin is the lead developer of one client. This is not about clients, this is about the protocol.

Actually, there has been one serious bug that resulted from the BIP 16 patch, and changes so many different things at once that it's quite possible it could create security or other bugs. BIP 17 has no serious technical or theoretical concerns, just "what if there's already a bug in the current code?".

Reality is that one large pool and at least one small pool are already voting for BIP 17. Another large pool plans to add it as soon as possible, probably within the week.

The problem with BIP 16 itself is in the protocol changes. While it's possible to debug the client's implementation, that will never fix the protocol-level inconsistencies. On the other hand, there has been some talk of using transaction version 2 to implement BIP 16, which could result it in being made somewhat consistent. I hope something comes of this, and I plan to Withdraw BIP 17 if it's a sensible protocol change, despite the potential implementation risks.

This applies just as much with BIP 16/17 inverted, except that unlike BIP 16 (due to its complexity), BIP 17 is easily proven to be "probably good" by any C++ programmer.

Only BIP 17, and only if someone actually wants/needs it, then. :p

For what platform?

It's not obvious, but your choice is your own.

At least pool.itzod.ru, and you can use BIP 17-patched bitcoind with p2pool. I think EclipseMC might support BIP 17 as well, but I'm not sure if they have the patch deployed live yet.

Edit: It looks like pool.itzod.ru maybe failed to do it right, and is producing BIP 16 blocks? :/

Edit: Looks like those were made before applying the patch, and they hadn't yet found a block with it.

Would be nice if PiUK would make a BIP 17 pie chart and block breakdown...

It's hard when Gavin makes it seem like I'm the only one who want BIP 17, so the other big pools take the chicken-and-egg position (we won't support it because nobody else does). slush was leaning toward supporting BIP 17, but apparently changed his mind after Gavin linked the still incomplete summary of developer positions implying it was an accurate representation.

I was considering making a video series on the proposals in layman's terms, but I simply haven't had time, nor am I really sure how I'd handle making the actual video (I suppose if it wasn't for the time issue, I could get together with someone else local involved in Bitcoin and have them record it...).

I'm not aware of any pool running on pre-compiled binaries, but I'd be glad to provide assistance if any need it.

Gavin seems to be ignoring BIP 17 and forcing everyone to support BIP 16 as much as he can, but he is basically alone in actually opposing BIP 17 (not counting people who oppose both).

BIP 16 is risky because it modifies a lot of code unrelated to P2SH.

BIP 17 is risky because it exposes part of the current system that we don't currently use regularly.

Neither are perfect. I prefer BIP 17 because it mostly leaves the current system alone, and can't introduce new problems.

AIUI, no.

There are much more important fixes that need to be made for Bitcoin to scale, and they are hard-forking.

BIP 17's first week of "voting" is starting. Please merge the branch or apply the relevant patch ASAP. My git repository also has backports tagged back to v0.3.19. If you want to retain BIP 16 support (that is, support both BIP 16 and 17 simultaneously), or need any other custom port, please send me a PM or ping me on IRC with the version you need it for.

BIP 17 is not only simpler and easy to audit, but it has already had extensive QA testing even on mainnet, so it doesn't have the risk of breaking something random unrelated like transaction fees.

Oh the irony... the first bounty is used to imply there is no such evidence, and the second bounty to imply there is?

On another note, my bets are on "there was no such cited illegal activity before, but there will be soon now that it's been (effectively) suggested"

This thread is basically lying.

Just upgraded to bitcoind next-test (pre-0.6 + working pull requests) on Eligius. Seems to have gone fine, but let me know if anything seems off.

Note that this upgrade means we cannot go back to pushpool at this point (without reverting it of course) since the bitcoind maintainers no longer support solomining via getwork (it requires a lot of patches, some Eligius-specific which I didn't take the time to add to 0.6).

The only reason he could steal the transactions was because the BIP was not active. If it was active, he could not have done it. After he did it, it was a simple matter of enabling the BIP to bypass it. I disagree that a BIP-16-stealing bot would be a lot harder: we already have a "hub mode" patch to connect to a lot of nodes, and all one needs to do is modify the output address for every transaction they relay. I could probably finish it in under 10 minutes, but honestly I have better things to do, and giving people trying to test BIP 16 a hard time isn't my idea of productive since (for both BIPs) it isn't a practical real-world attack.

As I've said before, while BIP 17 is the best solution right now, I have no objections to a similarly clean solution being used. I'm fine with spending more time to address any concerns with it, including a "remake" if that's wanted.


After giving this some thought, I believe I do owe Gavin a public apology for not spending more time proposing BIP 17 earlier, before he spent all that time on BIP 16.