To be honest, the state of the current mining situation makes it extremely easy to make this switch rather safely. As long as the major pool operators are in agreement, easy. You can have over 70% of the mining power with 5-6 individuals. Or ideally those 5-6 individuals will vote AGAINST it in this case... |
|
|
|
|
I propose OP_NOP1 become OP_CODEHASHCHECK (therefore this proposal is called "CHC"). When this instruction is encountered, it:
1. Extracts all the code in scriptSig from the last OP_CODESEPARATOR (per static analysis) onward
2. Performs a HASH160(code) - call this the "codehash"
3. Compares this codehash to the top item of the stack
4. If this comparison fails, aborts the transaction as a failure
This should be safe, staticly analyzable, and sanely compatible with the existing scripting system.
One downside: there is zero protection enforced by old clients (/P2SH/ at least verifies the spender knows the correct script). I consider this a non-issue since an attacker can find out the correct script as soon as the legitimate spending transaction gets relayed, and so long as the CHC miners have well over 50%, it should be fairly safe by the standard 6 confirmations.
|
|
|
|
As long as there's an old version on Git that has the code I don't see why it needs to be in current versions any more. Anyone who wants it can just grab a version that had it. I look forward to FPGA support and hope it will be modular enough that hardware devs can easily add their specific device support whether it be USB, JTAG, serial or whatever.
The BitForce FPGA support is itself only about 250 lines of code. The refactor I wrote first replaced/touched nearly 900 lines, making it easy to add new mining devices. |
|
|
|
|
CPU mining is still useful for testnet, at least. Perhaps just make it clear on downloads that any further CPU-specific enhancements need to be funded by a donation, or submitted as a patch?
Edit: To clarify, I do NOT think any effort should be spent improving CPU mining, but at the same time, I don't see any reason to remove it or reject improvements from others.
|
|
|
|
I expect to get well over 70% support starting Feb 1. Hopefully more than 30% of miners have enough common sense to oppose. |
|
|
|
It basically makes a special-case out of a specific template. This is like saying "if you see a program that does X, instead of executing it, execute something else instead".
No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation." Ok, so "if you see a program that does X, after executing it, execute something else or you risk losing money"... As for saying something in BIP 16 about obsoleting scriptPubKey : no. Although I think in the future we'll move towards all transactions being pay-to-script-hash, I think it is dumb to put anything like "we think this is what is going to happen in the future" into standards documents. Deprecation is a common thing in standards documents - just look at all of it in the HTML specifications if you want an example. In any case, this isn't merely "we think this is what is going to happen in the future", it's "what it happening now: scriptPubKey is no longer considered standard, just tolerated/accepted for compatibility". This is implied by abusing it for backward compatibility, but should be explicit. Can we keep the big picture in mind? The reason I'm pushing so hard for "send bitcoins to a multisignature-protected-address" functionality is so users stop losing their bitcoins to malware infecting their computers and smartphones and to scammers. OP_EVAL did that just fine. We can spend more months arguing over trivia, but I would much rather we spent the time thinking hard about, and building, great wallet and escrow solutions that solve Bitcoin's biggest technical problems. Breaking the protocol is not trivia. |
|
|
|
|
/P2SH/ should be Rejected as-is. It's at the very least worse than OP_EVAL, and broken by design.
It basically makes a special-case out of a specific template. This is like saying "if you see a program that does X, instead of executing it, execute something else instead".
The only excuse for this kind of design would be if scriptPubKey were to be deprecated (recommended against all future use, but still supported during a [long] transition period), and this special-casing is a strict backward compatibility mechanism. The current BIP 16 does not (explicitly) say this is the case.
Either BIP 16 should be revised to explicitly deprecate scriptPubKey, or Rejected and replaced with a revised OP_EVAL or some other sane solution.
|
|
|
|
just remember for the time being all RS requests in his license is to ask perms and that you won't be attempting to attack SLC with your project. This requirement is non-free and cannot be used with free software. Well it can be used w/ MIT license as MIT has no copyleft provision. It is most definitely incompatible w/ Oracle's license though. Mixed with MIT, would still make the final program non-free. |
|
|
|
just remember for the time being all RS requests in his license is to ask perms and that you won't be attempting to attack SLC with your project. This requirement is non-free and cannot be used with free software. |
|
|
|
He/we did nothing apart from put hash onto the coin to mine it. Same here. |
|
|
|
1) Was there a 0.4.2 did I miss something ? There was, but it was git-only: no binaries were built. 2) Are there changes which break the GUI Client for 0.4.3 ? Unknown. Nobody is testing, nor seems to care. Probably not. |
|
|
|
Let's make the rule really simple: blocks are invalid if there are tx'es older than 8h not included. What do you think? I'd "time" them in blocks. What if there are too many to include in a single block?  |
|
|
|
Your guys' call. We've got plenty to do at BitTalk.TV to not worry about this, but if you think a "Most Promising of 2012" awards ceremony would be better, I'll reformat to that instead. I think 2012 should be done in a year, and 2011 now. :p |
|
|
|
I wonder if we'd have this thread if luke-jr and eligius had been left in almost every category like they had been at one point...
The poll results suggest "yes". |
|
|
|
Now that the scammers are (at least mostly) gone and shut up... I'm offering a 50k CLC bounty to a practical, technological solution to my monopoly on CLC. If there are multiple people involved in the solution (eg, one person designs it and another implements it), I will decide how to split it up among them. I'll say straight off, that this does not include "solutions" like the all-too-common FUDing and slander, nor special-casing to my particular blocks (that is, I should still be able to mine like everyone else after it's fixed), though fitting to the particular nature of this monopoly is acceptable. When/if this solution is implemented, I will consider CLC to have made a legitimate contribution worth leaving it alone. Bonus points if you can give it also a legitimate long-term use to bring it fully out of "scamcoin" status, and then I'll offer it as a merged-mining option on Eligius. |
|
|
|
sorry for OT but did this ---v really happen? I only heard about the 'random' text in block headers. Speaking about law, how "lawful" is using the hashing power of your pool to perform an attack? Without informing the users mining there?
It's slander, nothing more. |
|
|
|
Of course reverse engineering the solidcoin "bits" would be a violation of his closed source license. Reverse engineering is a fair use right under US law. As is interoperability (including overriding trademark law). |
|
|
|
bitcoind version 0.4.3 is now available for download at: http://luke.dashjr.org/programs/bitcoin/files/bitcoind-0.4.3/ (until Gavin uploads to SourceForge) This is a bugfix-only release based on 0.4.0. Please note that the wxBitcoin GUI client is no longer maintained nor supported. If someone would like to step up to maintain this, they should contact Luke-Jr. Please report bugs for the daemon only using the issue tracker at github: https://github.com/bitcoin/bitcoin/issuesStable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.4.3#.tar.gzBUG FIXES- Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download).
- Fixed some address-handling deadlocks (client freezes).
- No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak).
- Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed).
- Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr).
Thanks to everybody who contributed code or helped test this release: Luke Dashjr Matt Corallo Gavin Andresen Pieter Wuille |
|
|
|
|
Yes, I filed the DMCA takedown. If you have a problem with that, that's your problem for supporting plagerism and copyright infringement. The MIT license is not very hard to comply with. It has a single requirement: maintain the copyright line(s) and license text as-is. It is impossible to "accidentally" violate as RealSolid is supposedly claiming.
|
|
|
|
|
Show Posts
