(1) slow initial block chain download. Fixed in 0.5.2 (at least in some/many cases). (2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter). It's -rescan. It's also never needed in theory... (3) lack of wallet security (wallet encryption isn't offered by default, why?). Wallet encryption is mostly a PR stunt. In the end, you still can't back up the "encrypted" wallet as-is without losing privacy, and a trojan can just wait until you unlock your wallet. (4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up). This is the one biggest problem with Bitcoin-Qt right now IMO. I don't see any reason the AES code can't be recycled to encrypt the whole file when backing up. That being said, these are all off-topic here... Can a mod split it off (ideally in the Dev forum)? |
|
|
|
First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script. No, it doesn't. Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out. Much more likely there's a subtle bug in the more complicated BIP 16. Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails. That's what I thought, but I didn't see that implemented in the code. In any case, it's not relevant to CHV. So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL. It is inconsistent with the other opcodes, but that is required to remain backward compatible: it either makes the script fail entirely, or it functions as a NOP. On the other hand, BIP 16 is inconsistent with the whole script concept. Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic. How? The reason OP_EVAL caused controversy was that it wasn't statically analyzable. This does not apply to CHV. I heard nothing of a problem with new opcodes. Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey. At the end of scriptSig, the code from the last OP_CODESEPARATOR until the end is stored at the front of the stack. At the beginning of scriptPubKey, it is pulled off the beginning and put in a new variable only used by CHV. |
|
|
|
The insane thing is 28% of voters picked the first two options.
Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".
Yeah, I basically added those as a control for the poll. Their results tell me the poll is worthless. (1) why else would he post this in Mining instead of Development & Technical Discussion? Because it's the miners who are voting and in control of the situation. Yet somehow they're being kept in the dark and forced to vote a specific way... |
|
|
|
Gavin write OP_EVAL, you oppose. Hmm, what? I didn't/don't oppose OP_EVAL. You propose CHC, where's the code? A few posts above yours. Well, luke, if you implement your CHC idea before 1st Feb, maybe you'll get that monarchial powers .  I don't want monarchial powers. If people wanted a monarchial currency, they'd be using USD. I just don't want Bitcoin broken in a rush to get a new feature. |
|
|
|
Eligius- Ra, the new server, is online the same host and everything, ready for the moment we get to a switchover point. However, Eligius- Su has been finding short blocks, taking it further away. If miners wish to donate the rest of the buffer to me, they can switch their miners to use generous.mining.eligius.st to begin using Eligius- Ra early. When/if Eligius- Su's hashrate drops off to under 100 GH or so due to people moving to Eligius- Ra, I will take that as a vote to donate the buffer, and shutdown Eligius- Su, replacing it with Eligius- Ra. Either way, don't forget to update your Artefact2 stats links to use /7/ instead of /5/  |
|
|
|
Luke seems to think it's ok to do anything that *can* be done, I've never said anything of the sort. so I assume that for instance mining with him and not submit winning shares would be perfectly ok.
That would hurt yourself and other miners, not me in any direct manner. It's also detectable, and if I find anyone doing it, you can be sure I will block them. |
|
|
|
I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it-- (Just a side note, this is exactly how I feel with Coinbaser, which has been tested and in production for almost a whole year now...)I don't have any objection to push-to-script-hash in principle, and would prefer it be in soon too - I just don't want to see it done in a way we'll regret for years. I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better. OP_CODEHASHCHECK is in some ways even a bugfix (OP_CHECKSIG almost does it), and seems like it could be done with much less modifications than the other two schemes, in addition to being both (much easierly!) staticly analyzable and in form with the original script design. If there are real problems with this solution, please do share them, as part of making Bitcoin better. |
|
|
|
(As for the technical side - the issue seems to be that P2SH introduces a new interaction between the concept of "standard transactions" and the scripting system. Before, a transaction would be accepted if it was standard and the script returned success; now there's an additional requirement, which is that one of the standard transaction types now calls for you to rerun the script in a different way. This means that the "standard transactions" concept is now actually part of the scripting system, rather than a secondary sanity check, so it can't be fully dropped in the future. However, the special case is on the sender-script side, and I don't think allowing nonstandard scripts there was ever plausibly a good idea. I do still want to see the standard-transaction types broadened to include fancy tricks with time locking, but that's considerably less urgent.) That's a good point, but it's a negative point. "Standard" scripts is merely miner bias. It's a flaw that the software developer is allowed to force his biases on miners, as it is right now, and making "standard" transactions a protocol thing would make the problem even worse. Miners are free to choose what transactions they accept on an individual basis, and work should be done to make that easier, not harder. That is, "standard" transactions should be undefined entirely. Eligius already will accept any transaction, "standard" or not, without bias. While I disagree strongly with the monarchial powers being given to Gavin, that is not the basis for my objection to BIP 16 specifically. |
|
|
|
Luke, shame on you for just dropping this message and calling for a forum vote without giving people who disagree with you the fair time to write an opposing position. I've raised the issue with Gavin more than once. He seems to have been going out of his way to ignore it and force his decision on everyone. I can't just give him all the time in the world because he has set a deadline only a month away; so miner awareness needs to begin now. Analyiziability is important because its what allows you to make definite, accurate, statements about what a script will and won't do without actually executing it. It also makes it possible to write implementations of bitcoin with stronger concrete and auditable statements about their security. It's the property that lets you uphold the security principle of "validate input; then act on it". Because the bitcoin system's security comes _PURELY_ from software— it doesn't matter how great Gavin is, he can't reverse your transactions if they go wrong due to software bugs— its very important for the continued adoption of bitcoin that we be able to back it up with the most secure software possible. Please don't imply this is security-related, or that static analysis provides any security advantage. While it does optimize rule checking in cases that will never matter, it doesn't provide any practical benefit for security. Perhaps most significantly for me is this simple fact: Script was very clearly designed by Satoshi to NOT be turing complete, and considerable effort was made in this design to achieve this property. The second sentence of the description of script on our wiki says "It is purposefully not Turing-complete, with no loops.". It seems foolish to me to abandon a core design principle of script, one which greatly helps in reasoning about its security, without a darn good reason. And we don't have a reason at all— our purpose had nothing to do with turing-completeness, that was just a side effect. (the size limits of script and limited IO make it pretty hard to come up with anything where the turing completeness is actually useful) More foolish to abandon the concept of scriptPubKey being a script entirely (as BIP 16 does), yet still support it being used as a script. OP_EVAL wasn't perfect, but at least the script remained a script. What perplexes me more is that Luke stated he would withhold his complains if the 'other developers' announced that "Bitcoin 2.0" (whatever that would be) would only use P2SH style transactions and that non-P2SH would be deprecated. I think a lot of people who have considered this consider it a likelihood— the potential pruning savings of P2SH style transactions are tremendous and could significantly reduce spam risks, but no one can make promises about a future system which doesn't exist and may not involve the current developers or may never exist. I wasn't asking for any promises about the future. I was simply saying "if we're going to replace the script with a single hash, let's actually do that"; that is, the BIP should explicitly say "scriptPubKey is considered deprecated and is replaced with hashRedeemScript. For the sake of backward compatibility, hashRedeemScript must be formatted <like so>, and if it is found not to be formatted like this, it is to be interpreted as a legacy scriptPubKey for compatibility only." |
|
|
|
Luke.. from a miners position i got to tell you: Just stop it. You make yourself as ridicolous as RealSolid is for a long while and for the same reasons: in the last few days you act like an arrogant self-righteous asshole. I know you will end up telling us about freedom of open source and democtratic elections and stuff, but tell you what - i dont give a shit about that. I like the way bitcoin was handled till now and if Gavin decides one way i trsut HIM more than you to make the right choice since lately you have shown a grade of mental instability that is only comparable to RealSolid. If you want a monarchial currency, why not just use the Fed's USD? Gavin isn't perfect, and this is one example. Sorry you consider making people aware of a problem to be "mental instability". |
|
|
|
Can someone explain me ( us ) what is exactly the meaning of "safer-but-less-powerful"?
What are we going to miss? As it's not an actual extension to the scripting language (as OP_EVAL and OP_CODEHASHCHECK are), you basically cannot use it in combination with (an actual) scriptPubKey. It's either or. |
|
|
|
Not sure if you've all been following the latest push-to-script-hash (p2sh aka OP_EVAL) discussions. OP_EVAL was Rejected because it isn't staticly analyzable (this is a useless property for Bitcoin scripts, but a nice-to-have attribute for idealistic reasons). Now Gavin has proposed a new BIP 16 "/P2SH/" to replace it. However, this replacement is far worse: it basically replaces the scripting system Bitcoin is built on with a single special-cased template. While this might be fine if BIP 16 actually proposed abolishing the current scripting system (while using the templated design to retain backward compatibility), it does not explicitly say so, and Gavin refuses to make this implied decision part of the specification/BIP. In effect, what BIP 16 proposes is the same thing as if a computer were to look for a specific program and stop you from using it unless your computer had a magic USB key for it (that is, it's not the program checking for the USB key, which would be the sane solution, but instead the computer that would be running it). Since this is a protocol change, Gavin cannot, however, go ahead with it entirely on his own. He needs at the very least a majority of miners to go along with it, and he's mentioned 70% as the cutoff point. Here's the catch: Gavin is forcing everyone using the latest Bitcoin code to vote for BIP 16. If you want to oppose this insane protocol change, you will need to modify your bitcoind source code or you will be voting IN FAVOUR OF IT by default (as of git master commit 922e8e2). I have written code that allows you the freedom to vote for (-p2sh) or against (-nop2sh): https://github.com/bitcoin/bitcoin/pull/755You can apply it to your bitcoind code like so: curl https://github.com/bitcoin/bitcoin/pull/755.diff | patch -p1 Tycho (DeepBit) has expressed dislike of /P2SH/, but has not yet committed to opposing it either. To stop this from going through, the easiest way to achieve the needed 30% is with the support of BTC Guild, BTCMine, EclipseMC, and Eligius combined. However, every little bit helps! Also, there ARE other solutions to the P2SH need/problem. A compromise between OP_EVAL and BIP 16 would be workable, and there is at least one eval-less proposal that is even easier to statically analyze without breaking the scripting system (CODEHASHCHECK aka CHC). Gavin has thus far ignored this because he just wants to rush into a protocol upgrade to get two-factor addresses out there. For reference: Please let me know if your pool will support or oppose BIP 16. Luke Eligius P.S. Why is static analysis useless for Bitcoin? Because you need to evaluate all scripts to validate them anyway. Sure, you could reject invalid ones with too many signature checks early, but there are equal and better ways to attempt a DoS without these (for example, including exactly the maximum signature checks, then failing for some entirely unrelated reason). |
|
|
|
Looks like Gavin's idea of a vote is forcing people to vote in his favour unless they edit code. If you run latest git master, you are voting for this terrible proposal. Merge https://github.com/bitcoin/bitcoin/pull/755 to get a choice (-p2sh or -nop2sh) |
|
|
|
I just pulled p2sh into master, replacing the OP_EVAL code that I pulled last month before the controversy erupted. So how do people using master vote against /P2SH/? |
|
|
|
should an individual who comes up with a unique method to advance Bitcoin commerce not file a patent? I was with you up till this. Patents are not protection. Patents are monopolistic abuse. |
|
|
|
Bitcoin version 0.5.2rc1 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/test/This is a bugfix-only release based on 0.5.1. Please report bugs by replying to this forum thread. Stable source code is hosted at Gitorious: http://gitorious.org/bitcoin/bitcoind-stable/archive-tarball/v0.5.2rc1#.tar.gzBUG FIXES- Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download; this was not a security vulnerability).
- 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).
- Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries).
- 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).
- Don't show "IP" for transactions which are not necessarily IP transactions.
- 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 Wladimir J. van der Laan Gavin Andresen Pieter Wuille Dylan Noblesmith |
|
|
|
For me, even windows is free   No, it isn't. To be free, you need to be able to legally: - run the program, for any purpose
- study how the program works, and change it so it does your computing as you wish
- redistribute copies so you can help your neighbor (including selling it)
- distribute copies of your modified versions to others
See also: the free software definition |
|
|
|
|
Show Posts
