Like I said, unless you can bring something to the table of substance, this debate is over. Support in this context is applied to the BIP, no matter how you want to erroneously define the definition of "support" to fit your failed chain of logic.
Gavin Andresen, the author of BIP 16, supports my interpretation here: 2) If, as a solo miner with an old client, compiled from source, wanted to vote in favor or against the P2SH, what changes exactly would I have to do to the source? ...This question is strictly about adding the vote cast, nothing else. What change(s) are necessary for that?
Don't do that, please. "Voting" with your coinbase should mean you actually do the extra validation required by p2sh, otherwise you're saying you support a feature when you really don't. EclipseMC makes the same error the other way around. Support the feature without announcing it in the coinbase like the BIP says. |
|
|
|
I like whoever proposed that the string in the coinbase refer to the BIP, in the future that's the way it should be done.
There is a problem with this approach. Due to FUD spread by some people (well, mostly one), many see this as a kind of "vote" unrelated to the actual implementation of BIP 16. Just put /P2SH/ in the coinbase to "vote". If miners "vote" without actually validating the pay-to-script-hash transactions, there will be a miscount and chain splits may occur. This is even more dangerous to BIP 17. If I understand this correctly, until more than 50% of the hashing power validate BIP 17 transactions correctly, anyone can steal a BIP 17 transaction before it enters a block. If a large pool "votes" BIP 17 in the coinbase without actually supporting the specification, this may well happen. |
|
|
|
About voting with hash power, I think that can be the right way to do such changes, but pools complicate that a bit. It's a bit late now, but if there will be more such voting in the future, then perhaps it would be an idea to implement some sort of voting inside BitMinter. Say you vote on the website and the pool creates votes in the blocks we make to match how much hash power in our pool voted for the one or other option. The choices in this case would be "BIP16", "BIP17" or "blank". This would allow each miner to use their hash power the way they want.
I think calling this a "vote" is misleading. To cite BIP 16: To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time.
To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create. Never ever put "/P2SH/" in the coinbase to state an opinion unless you actually have upgraded bitcoind to validate P2SH transactions as specified in the BIP, or there will be a miscount with consequences as described. For BIP 17 this is even more important, because BIP 17 type transactions can be stolen by anyone until more than 50% of the hashing power correctly validates the transactions. If e.g. Deepbit choose to "vote" for BIP 17 without actually validating the transactions, any BIP 17 type transactions can be stolen before they reach the block chain. (This has been demonstrated on the testnet, where people have fun stealing luke-jr's test transactions.) IMHO BIP 16 is the way to go. BIP 17 has support from one developer while the rest support BIP 16. BIP 17 will probably never gain the support it needs, and only delay the process of getting multisignature transactions into Bitcoin. Multisignature transactions are important for security reasons. Especially for larger companies where large transactions needs to be signed by at least two persons. |
|
|
|
I agree that support applies to BIP 16, which is a technical specification of how P2SH transactions may work. A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. So which is it? Is it a technical specification or is it a design document that contains a technical specification? How can a technical specification contain a technical specification? Why would you be redundant like that, if you somehow managed to nest these? Is this some sort of esoteric Matryoshka doll on paper I am not aware of? Now you are nit-picking. A BIP is design document containing a concise technical specification. The technical specification of the new transaction type (named pay-to-script-hash in chapter 2) is in chapter 3 and often referred to in the rest of the BIP. E.g. in more than 50% of miners must support full validation of the new transaction type and later when it is described how miners should announce their support for the new transaction type, and how support can be counted to verify that more than 50% of the hashing power support the new validation rules. The reason why it is important to correctly count blocks mined by miners validating by the new rules is explained in the BIP as well: To gracefully upgrade and ensure no long-lasting block-chain split occurs [...] |
|
|
|
Like I said, unless you can bring something to the table of substance, this debate is over. Support in this context is applied to the BIP, no matter how you want to erroneously define the definition of "support" to fit your failed chain of logic. Support, however defined, still applies TO THE BIP, not to bitcoind, the protocol, etc... Therefore my statement stands and your argument is still invalid.
Again, your post is meaningless and you are wrong. If you think the BIP is wrong, take it up with whoever maintains it, if you disagree with me, provide anything to support your argument. In the absence of either of those, there is nothing more to discuss.
I have presented all my arguments. Just read my posts again to make sure nothing slipped. I have nothing to add beyond that. I agree that support applies to BIP 16, which is a technical specification of how P2SH transactions may work. See BIP 1: A BIP is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. Mining software (transaction validation is usually implemented in software) can support the technical specification in this BIP. There is no special mention of bitcoind or other software. Just the simple fact that the software must be upgraded to support this BIP. We obviously don't agree to what software support of a technical specification (e.g. a BIP) means. I think the BIP become pointless with your definition of to "support" a technical specification. Testing conditions like "To gracefully upgrade and ensure no long-lasting block-chain split occurs, more than 50% of miners must support full validation of the new transaction type and must switch from the old validation rules to the new rules at the same time." becomes impossible in the way described in the BIP if "/P2SH/" is reduced to a statement of opinion. We can just agree to disagree on this, and perhaps have a popular vote here in this thread. :-) |
|
|
|
The keyword here is support. This clearly means technical support of the specification above, and has nothing to do with anyones opinion of the specification. The purpose is to count miners which has implemented support for the specification, not miners who think that the specification should be supported (political support). It does not "clearly mean" any such thing. In fact, it clearly states exactly the opposite. You even requoted it in direct contradiction to what you just wrote: To judge whether or not more than 50% of hashing power supports this BIP.It says absolutely nothing about technical support. It clearly and exclusively states "supports this BIP." This is not in question. The fact that you are trying to make it say something else is duplicitous and just plain false. The word support can have a lot of different meanings depending on context. When an army patrol under attack calls for air support, they clearly don't mean the air around them should support their views, share their opinions or vote for them. A beam can support a roof. The beam does not have an opinion of it's own. The roof is supported by the beam from falling down, not voted by the beam to stay up. A man leaning on a wall for support does not depend on the opinion of the wall. He depends on the wall to stay put and keep him from falling down. There is also economic support, supporting actors or instruments, etc. My version of LibreOffice supports ODF version 1.2. It does not support the database format used in the standard Bitcoin client. Support can mean sharing a political opinion, but I already explained why that interpretation contradicts the purpose of /P2SH/ as described in BIP 16. Hashing power is not a person, and do not have an opinion of it's own. It can however support the technical specification much in the same way as a beam support a roof or LibreOffice support ODF 1.2. I think your interpretation contradicts the context, and I can only conclude that our understanding of the word support in this context differs. (This is an opinion which can be supported and voted over, not a technical specification which can be supported by software or hardware. :-) |
|
|
|
To be honest I haven't had time to read up on P2SH yet. But I will do so ASAP. I'll move my 2 Ghash/s from solo mining to BitMinter if you start supporting BIP 16! |
|
|
|
Definition BIP: Bitcoin Improvement proposal
Definition Vote: a formal expression of opinion or choice, either positive or negative, made by an individual or body of individuals.
Definition Vote: the means by which such expression is made, as a ballot, ticket, etc.
Definition Vote: the decision reached by voting, as by a majority of ballots cast: The vote was for the resolution.
Definition Vote: a collective expression of will as inferred from a number of votes
Definition Vote: to express or signify will or choice in a matter, as by casting a ballot
Take your pick, I gave you 5 definitions of Vote to choose from.
The keyword here is support. This clearly means technical support of the specification above, and has nothing to do with anyones opinion of the specification. The purpose is to count miners which has implemented support for the specification, not miners who think that the specification should be supported (political support). It would be very bad if miners put /P2SH/ in their coinbase to state their opinion without actually supporting the specification! This may actually be a problem with the specification. If more people understand support as political support, the change can be based on false assumption of technical support for this BIP. Perhaps this method of probing for technical support is the main problem with BIP 16, and should be abolished in favour of testing with actual transactions. Now let me highlight the relevant portion of the BIP that you are failing to understand:
...miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create.
I did not put that string into the coinbase transaction, it was put there for me.
This is a protocol specification not a description of one particular implementation. There are at least two independent implementations of bitcoin, and many more speaks or interpret the protocol or parts of it. Many pools create their own coinbase. You must know that by looking at the coinbase transactions in the blocks created by other pools. Standard bitcoind don't put the name of the pool in the coinbase, to take one example. For normal solo miners like me it is enough to upgrade the vanilla client. I have no intention of creating my own coinbase, and my limited knowledge of C++ says I shouldn't do to many changes to the code. If normal solo miners like me should be required to make this change by our own, the threshold for supporting BIP 16 (and I still mean technical support) and show it would be unreasonably high. Now go back and read again, and please tell me where it says that /P2SH/ is a [political] vote and not merely an indication of the number of blocks supporting pay-to-script-hash. Ok, done. Now go back and read it again, and please tell me where it says that /P2SH/ is an indication of the number of blocks supporting pay-to-script-hash? The only thing I see is this: To judge whether or not more than 50% of hashing power supports this BIP. It says nothing about supporting P2SH. It says supporting the BIP. Plain. Simple. Clear. Read it again. Now go back and read it again before responding. Now do it again, because you are not comprehending what you're reading. Once more, do it again. Maybe with 4 read throughs, it will sink through. And if you read it another time with my interpretation of the word support, I'm sure you will take my point. BIP 16 is a technical specification, not a political resolution. |
|
|
|
Sturle, you are a troll and I am wont to respond to idiots like you, but I will do it against my better judgement. Please calm down. I may be Norwegian, but I'm not that big and scary. ;-) P2SH in the block chain is intended to vote FOR BIP 16. It is not to indicate support for the ability to process P2SH transactions or not. That is a side effect. I already quoted the relevant parts of the BIP. Go back and read and comprehend what you are reading before responding. I have read it many times now, and I can't see any mention of a vote. It says: To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create. If a miner has upgraded the software (yes, it says right there that an upgrade will support BIP 16 transactions) the string "/P2SH/" should be put in the coinbase to indicate that support. It makes counting very easy. The purpose is even more clearly stated below: On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.
If a majority of hashing power does not support the new validation rules, then rollout will be postponed (or rejected if it becomes clear that a majority will never be achieved). See? No vote is ever mentioned. It is just a practical way of counting the combined hashing power of miners who have upgraded their clients to support this type of transaction. The alternative would be to keep feeding BIP 16 transactions to the network and see how many blocks include them. If you support BIP 16 transactions, you should put /P2SH/ in the coinbase to make counting easier and not postpone it for to long. Now go back and read again, and please tell me where it says that /P2SH/ is a [political] vote and not merely an indication of the number of blocks supporting pay-to-script-hash. I remember sometime back in 2010 (september?) when no blocks were generated any more due to a bug triggered by a non-standard transaction. All miners had to upgrade their clients, and the new version discarded non-standard transactions. This is an important reason why the simpler BIP 16 is preferred by most over BIP 17 and other suggestions, and it shows that a network-wide miner upgrade has been done successfully before. If each pool counts as one miner, the number of miners must be lower now than it was back then when no pools existed and people mined on their CPUs. |
|
|
|
BIP 16 is not universally accepted. BIP 17 is an alternative (which I am not voting for at the moment, either). One developer support BIP 17, and it is already very clear that BIP 17 will never gain popular support. For technical and other reasons (transaction size and fees imposed on sender, security, etc). BIP 16 was proposed on the 3rd of January, to be "ratified" by vote on the 1st of February. That timetable is absolutely, positively ludicrous for a change of this type, and that is currently the sole reason EMC is not voting for or against it. Until such time as I have time to evaluate it and/or the alternatives, makes the changes to my backend for the pool, deploy the changes and test them, then deploy the live backend, I will not vote for it. You already did the changes required for your pool. You didn't even answer if you undid all of them, or if you are just dishonest about it (miners support BIP 16 but don't put /P2SH/ in the coinbase). The stability of the pool for the miners is of paramount importance. I'm sorry that you feel that it's dishonest to want to maintain and stable, robust pool, but my opinion differs. Please! I don't believe you are that incompetent. You do not seriously think the six chartacters /P2SH/ in the coinbase makes your pool unstable, and you didn't answer if you removed support for BIP 16 from bitcoind or not. From what you write I suspect you of mining BIP 16 transactions without announcing it, which is dishonest and inconsistent with BIP 16 itself. Did you or did you not remove support for BIP 16? Did you do that by reversing the patch (and re-introduce OP_EVAL, which is bad), revert to an older version or patch it yourself (so much for stability)? The fact that the vote is "forced" when you upgrade is also a red flag, as I already mentioned. If it was a perfect plan, a forced vote would not be required and everyone would be scrambling to enable the vote. As it is, the reception seems to be luke warm at best, indicating to me that there is little interest (and therefore little need) at best and flaws at worst. Support for BIP 16 is introduced when you update, and so is the announcement in the coinbase. This is to comply with BIP 16, which states that miner supporting BIP 16 transactions should include /P2SH/ in the coinbase to indicate the fact. There is no forced vote. You can decline to upgrade, and stay with a version not supporting BIP 16. Additionally, I think you are the one who is confused as to what the point of the P2SH vote is for. It's not to show what miners support it, it's to show what percentage of the hashing power supports BIP 16 and in the case of EMC, we do not at the present time. Therefore removing the P2SH coinebase is exactly what is required by the BIP. Let me quote the relevent part of the BIP: https://en.bitcoin.it/wiki/BIP_0016To judge whether or not more than 50% of hashing power supports this BIP, miners are asked to upgrade their software and put the string "/P2SH/" in the input of the coinbase transaction for blocks that they create. I did not put P2SH in the coinbase, it was put there for me without my consent. This angers me. I thought that was obvious. /P2SH/ is there to indicate the fact that the miner accept BIP 16 transactions. Is it possible to write it more clearly? Otherwise the vote would be meaningless the way it is described. The new bitcoind does this automatically. Many pools generate their own coinbase, and need to patch their software to do the same when they choose to support P2SH. If you think changes to bitcoind needs your consent (really? :-D), you should write your own version. I doubt the developers will ask for your consent for every change they make or new feature they introduce to bitcoind. There is nothing in the BIP to indicate the P2SH vote is to show what block miners support P2SH, only what block miners support the BIP. If this is incorrect, the BIP needs to be fixed, not the other way around. I do not support the BIP because of the timetable. Given time, I may support P2SH or a revised BIP.
So you have removed support for BIP 16 transactions from your bitcoind? |
|
|
|
Because the timetable is too aggressive for proper testing/vetting and deployment.
I am also not convinced that it is the proper solution to the problem. I'm not saying it's not, either - but a 4 week timetable for deployment of this magnitude is unreasonable and irresponsible, not only from a blockchain (Miner upgrade) perspective, but also from a pool operator/backend perspective.
Different options have been discussed and implemented for a great deal more than 4 weeks. No point in just sitting on the code and wait. Wait for what? And I did not use it to vote against P2SH, we were never voting FOR it, simply because the timetable was too aggressive. As it happens, some other issues caused a premature upgrade which briefly enabled a force vote for P2SH. That alone should signal a major problem, when a change requires stealth to be slipped into the codebase. It's like tacking on riders on bills in Congress - yeah vote against child porn! Oh, by the way, we are attaching this little rider to say that we can confine you in GitMo without due process as well... but if you vote against this bill, you're for child porn!
Like I said, and I thought it was clear, but apparently not. WE are not voting for or against it, we are simply not voting at the present time.
Force vote and child porn!? Congress? Seriously. Do you support P2SH, or did you remove that part of the code as well? Because now you are confusing. I thought the entire point of the vote was to show if the miner supports P2SH, to make it possible to switch P2SH on when the network is ready. If you support P2SH without announcing support, you are simply dishonest and sabotaging the vote. P2SH was implemented by a strong majority among the developers. Pulling the support into git and enabling it was only the next natural step. How can you make a majority of miners support P2SH in any other way? |
|
|
|
EMC voting for P2SH was a mistake and has since been corrected to remove P2SH votes.
Why did you decide to use EMC's users hashpower to vote against P2SH? |
|
|
|
so updating to 0.5.2 = vote for P2SH
staying with 0.5.1 = vote against P2SH
that doesnt sound right , there are ~900 "no vote" blocks
Yep. I have deleted my post. My source was the topic in #bitcoin-mining, and it was set by luke-jr. Never believe a word typed by luke-jr! When checking the facts, nothing checks out except for Eligius (his own pool) using his own special version which all the main developers think is bad for many good reasons. Examining blocks from EclipseMC shows that the pool supports P2SH. And for casual solo miners and p2pool miners to support P2SH, you need to pull bitcoin from git and compile it yourself. I think that is making the threshold for voting for a better future for Bitcoin far to high. |
|
|
|
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. i kinda agree, can't see too much consensus in the dev team either so a little more brainstorming could be needed  I can't see any better implementation yet. This has already been discussed for a long time. 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 has the greatest support by a large margin, so please let us just get BIP 16 out there. |
|
|
|
|
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.
|
|
|
|
|
Seven pages(!) in today's Dagens Næringsliv, the largest financial newspaper in Norway. The journalist has done good research and even visited the European Bitcoin conference in Prague. Very good article. Paper only, unfortunately. One of five headlines on the front page.
|
|
|
|
|
Berlin! Berlin! Berlin!
You won't regret it. Berlin is a wonderful city! It is young and full of life and culture, and also history. And it is cheap. And it is not going to be on it's head and full of security theatre due to some sports event, which probably many Londoners would like to get away from as well.
|
|
|
|
SOPA mostly deal with online piracy, and pirates don't pay for the things they download. They didn't pay with fiat back then, and they are not going to start paying in bitcoins now.
Remember allofmp3.com? A Russian online store selling all kinds of music from all artists and all labels in various unprotected formats. The company never transferred any money to western copyright holders. |
|
|
|
I have found owners to three of those addresses. All of them are people I have sold coins to on #bitcoin-otc, and I guess they have bought coins from other people as well. I have checked the rating system, and the users have not been rated by anyone at the date of the transactions involving stolen funds. None of them are around on #bitcoin-otc any more, so further investigation will be difficult. The largest transaction involved was 10 BTC, the smallest only 0.001 worth of stolen funds, so I'm not sure if it is worth the trouble. |
|
|
|
Even if you haven't, be sure you're using a strong password and not using the same password among sites.
A Yubikey may be worth all your bitcoins. Get one and use it. At least for withdrawals. |
|
|
|
|
Show Posts
