I installed this version and it worked just fine initially. But now every time I try to run it I get a DEP violation. Does this version of the official client really execute code from the stack or other protected data only memory areas?!?!?!?!? I'm assuming "DEP violation" is some kind of no-execute thing? AFAIK, no Bitcoin-Qt does this. Since you mention it worked before, I would be concerned that perhaps you've been infected by some kind of virus/trojan. I suggest getting your wallet.dat off that computer ASAP just in case, then looking into it further. |
|
|
|
All of the BIP 12/16/17 stuff is mostly engineers arguing over whether it is better to use a nail, a screw, or glue to put two pieces of wood together. Since we're trying to keep this non-technical (I'm not sure that's a good idea, so click the links if you can handle the details!), I'm going to try to come up with a more accurate analogy: - BIP 12 (OP_EVAL) is inventing a touchscreen for your home security system. You can basically do whatever you want with to authenticate.
- BIP 16 is inventing a camera+touchscreen, but due to patents/closed-source or whatever you can only get it from one security company, and can't use any other security system in combination with it. Everything must be done through the touchscreen.
- BIP 17 (CHV) is inventing a lock mechanism that can be opened by not just the old flat keys, but also by various combinations of any of these old keys or pretty much anything imaginable, without an abstraction layer like the touchscreens.
Slush has stated that he supports P2SH and his pool is much more than 2 percent. I'm not quite sure which BIP he prefers, however. Slush indicated to me that he isn't interested in researching the options, and will just go with whatever Gavin tells him to do. Luke-jr initiated a rumor that Gavin is hired by some company going to produce hardware/software solution for 2-factor authentication and this is the reason he is pushing so hard. This was mere speculation in private, IIRC when asked why Gavin is rushing things. I have no evidence, and haven't even looked at TruCoin's website to see if this might possibly be the case. I just believe it's unhealthy for a few individuals (including you) to hold too much power over the development of Bitcoin. This applies to Gavin as well. "I'll just go with what Gavin says" is a bigger problem than "I'm mining on Deepbit" right now: DeepBit at least cut down on advertising due to concerns of the centralization, but Gavin seems to be encouraging the "just trust me" attitude. CHV (BIP17) also executes data, as does OP_EVAL (BIP12). The debate is over how to execute the data, not whether to execute it. No, BIP17/CHV does not execute data from the stack as BIP 12 and 16 do. this is actually good - because this is a vote on a technical issue. if you cant apply the patch you shouldn't vote. One problem IMO, is that Gavin has merged BIP 16 into git master, and set it up to force everyone using it to vote for it. To not vote you have to patch your client. I submitted a fix to make this optional 2 weeks ago and while he did say he'd accept it with a minor change a week ago (which I made immediately), it still isn't merged.
For the record, I agree with the many people who think we should give this more time. However, my interest is only in avoiding the deep protocol change that BIP 16 makes, so I am fine with compromising on getting BIP 17 deployed sooner. Also note that while BIP 16 might arguably be slightly simpler/deterministic in the specific implementation used in Bitcoin-Qt, BIP 17 is almost certainly generally simpler to implement, and in practice much simpler in terms of backports to bugfix-only bitcoind and Bitcoin-Qt clients. |
|
|
|
Personally, I'd love to see Haskell code being used for that. It _is_ a rather big dependency though. Haskell code is, to the best of my knowledge, completely sandboxed if you disallow usage of IO Monad. Haskell is a strictly typed pure functional language which gives it some very nice properties, especially when writing code that needs to work just right and have no surprises. Maybe the future BIP 12/16 replacement can evaluate Haskell?  |
|
|
|
if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast. ... and with every such proposal, lack of network support means the transactions can all be stolen as soon as someone else tries to redeem them. Not really much better. |
|
|
|
IsStandard() is a permanent part of the protocol with BIP 16.
Can you elaborate why that's the case? If true, I think it's very bad. IsStandard() needs to be lifted at some point (probably when there is a suite of tests around each and every opcode that verify that it does the specified thing and leaves all execution context in a valid state). Gavin is correct that the actual function named IsStandard() could be removed or replaced. However, with BIP 16, all implementations are required to check for the specific BIP 16 standard transaction and treat it differently. |
|
|
|
With BIP 17, both transaction outputs and inputs fail the old IsStandard() check, so old clients and miners will refuse to relay or mine both transactions that send coins into a multisignature transaction and transactions that spend multisignature transactions. BIP 16 scriptSigs look like standard scriptSigs to old clients and miners. The practical effect is as long as less than 100% of the network is upgraded it will take longer for BIP 17 transactions to get confirmed compared to BIP 16 transactions. Since scriptSigs must always follow scriptPubKey, does this really make a big difference? ie, if people can't send them, they can't receive them anyway. So far, I favor BIP 16 because of this point alone. Eyeballing the client version distributions suggests that roughly 70% of users are running clients older than 0.5. We probably can't expect that 70% to upgrade anytime soon. BIP 16 has the some problem as BIP 17 when sending to them. Incidentally, I agree with sentiments expressed elsewhere on this thread that IsStandard() should be replaced with actual resource consumption metrics in the scripting evaluation engine. It seems fairly straightforward to assign a cost to each opcode and fail any script that hits the resource limits. That seems both more flexible and more durable than IsStandard(). IsStandard() is a permanent part of the protocol with BIP 16. |
|
|
|
Pick the three largest pools. Look at their fees. Those fees.
So use Eligius, not the three largest pools. Solved. |
|
|
|
Also, what's the point of low variance when you earn less anyway due to fees? What fees? |
|
|
|
Shouldn't we all push for decentralized pools, like P2Pool ? I'd love so see a bitcoin client with p2pool-technology built in; bring back the "generate coins" option! I implemented one a month or two ago, with support for ButterFlyLabs's BitFORCE... If I was a pool operator, though, I'd be thinking about other bitcoin-related businesses where I could use my expertise p2pool is nice, but it competes more with solo mining than pools. Short of some breakthrough idea, p2pool can't provide the low variance that the current centralized pools do. |
|
|
|
|
I set the vote/deadline for BIP 17 soon because I figured Gavin wouldn't accept any delays. If Gavin is willing to tolerate a later schedule for BIP 17, I can update it.
|
|
|
|
So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?
Eligius is on board for BIP 17. |
|
|
|
They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions. They wouldn't be validating them in any case. This backward compatibility allows them to keep working with transactions they do recognize. The permissiveness being "exploited" (at least for BIP 12 and 17) was put there expressly for this purpose. It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them. The change you're describing requires 100% of not just mining power, but also all users (including merchants who may be unable to upgrade for various reasons). The backward compatibility in BIP 12,16,17 allows upgrading the network with only a super-majority among miners' consensus. P.S. It also occurs to me that as a "democratic money" that this process is exactly the way it should happen. Trying to exploit the permissiveness of old clients feels like it's subverting what should be an, albeit painful, but consensus building exercise. This change is actually fully in line with "democratic money"; what Bitcoin is, at the core protocol, is in fact " unanimous money". I think that what it achieves is only a short-term solution, and will quickly need to be supplemented to be worth using in the long term - whereas /P2SH/ looks to me like a more complete option. The only long-term benefit of BIP16 over BIP17 is that you can fit more multi-factor addresses into a block before the inevitable Bitcoin 2.0 upgrade is needed. If we do end up needing that much before Bitcoin 2.0, we can roll out something similar to BIP12/16 at that time, presumably after we've had many more months to consider the consequences. |
|
|
|
I can't see any better implementation yet. BIP 17 is implemented. This has already been discussed for a long time. No, it really hasn't been going on very long. BIP 16 is a good solution, and the only way to get there in the near future. Neither longer addresses and blockchain bloat, nor turing completeness in the scripting language seems like better solutions to me. BIP 16 is terrible, and de facto protocol breakage. BIP 17 can get us there tomorrow if we really need to rush. It doesn't require longer addresses, nor bloat the blockchain (in fact, it saves more space than BIP 16 does!), nor is it remotely turing complete (it doesn't even require an eval-like function at all!). |
|
|
|
Let me try again for why I think it is a bad idea to put anything besides "push data" in the scriptSig:
...
That turned out to be a bad idea, because one person controls what is in the scriptPubKey and another the scriptSig. And BIP 16 makes this true again: the receiver now controls (to a degree) both scriptSig and "scriptPubKey". BIP 17 retains the current rules. Little known fact of bitcoin as it exists right now: you can insert extra "push data" opcodes at the beginning of the scriptsigs of transactions that don't belong to you, relay them, and the modified transaction (with a different transaction id!) may be mined. You can insert extra non-PUSH opcodes too, and mine them yourself... Basically, we already can put non-PUSH stuff in scriptSig, so if there is a vulnerability here, it's already in effect. As for backward compatibility & chain forks, I think I would prefer a clean solution rather than one that is compromised for the sake of backward compatibility. Then I would lobby to get people to upgrade to clients that accept/propagate the new transactions and perhaps create patches for some of the more popular old versions designed just to allow and propagate these new types of transactions. Then when it's clear that the vast majority of nodes support the new transactions, declare it safe to start using them. Any stragglers that haven't updated might find themselves off on a dying fork of the block chain…which will be a great motivator for them to upgrade. Are you volunteering to make that happen? After working really hard for over four months now to get a backwards-compatible change done I'm not about to suggest an "entire network must upgrade" change... I think just about every developer agrees with Gavin that this is not worth a blockchain fork... |
|
|
|
Why do you say there's no practical need? One practical need is to determine a priori whether a script is too computationally expensive to be allowed. With OP_EVAL, I could push some code on the stack and evaluate many times over… …and then stop evaluating when you hit the limit. Even with a static-analysis limit in place, I could waste just as much of your computation time by putting just under the limit, then failing with OP_0 or such. Knowing the cost beforehand doesn't stop any known attacks. Here is a BIP 17 transaction on testnet created with my new checkhashverify branch. Please help test/review! |
|
|
|
Can someone remind me why BIP-12 has fallen out of favor? OP_EVAL might add some amount of flexibility (regarding where a script is defined vs when it is actually executed), but none of these proposals seems radically different form one another.
BIP 12 cannot be statically analyzed. AFAIK no practical need for static analysis has surfaced yet, but so long as things are being rushed, it's not safe to say they won't in the future either... |
|
|
|
I'm wondering, which of the two approaches is easier to deprecate?
Or is it cut in stone after it is deployed?
Imagine somebody comes up with a new way of doing multisig in a year and everybody agrees that it's the right way. It's easy to deprecate (= stop using) just about anything. However, dropping support for it is not quite as simple - in any case, we'd need everyone to spend transactions still using it. Also what approach makes it easier to add new features on top of?
Think of the list of features for the next couple of years and see if the discussed multisig proposals fit nicely or not. BIP 12 is the most flexible. BIP 16 gets a one-shot at changing any aspect of the scripting system (and it's being wasted on merely recounting sigops...). BIP 17 cannot change any scripting fundamentals, but can be used for one additional check at any part of a scriptPubKey. If BIP 17 is deployed, something like a combination of BIP 12 and 16 could be still easily used in the future as an upgrade. |
|
|
|
After reading all of this discussion, I have now upgraded bitcoind to 0.5.2 on my miners (I mine solo), and encourage all other miners to do the same. I will also encourage pool operators to upgrade and announce support for their pools. Bitcoin needs this functionality now, not later. But not in the form of BIP 16. |
|
|
|
Luke-jr is lining up pool ops to go his way on it. ... Basically, it is Luke-jr's way or the highway and all others be damned. If the other pool ops didn't agree with "my way", they certainly wouldn't be voting that was just because I said to. The only pool op I know of that plans to vote for BIP 16 is doing so because Gavin said to and he doesn't want to look into the details. |
|
|
|
BTW - I'm a software professional, not a n00b. I've even used libcurl in the past with Visual Studio C++ before. The mingw32 thing is new to me. Fine, a n00b software professional... |
|
|
|
|
Show Posts
