Bitcoin Forum

Hi,

after stumbling upon and reading about this P2SH thing, I can't seem to find the answers to my two principal questions.

1) Will the implementation break compatibility with old solo mining clients?  I assume that when someone is solo mining and producing blocks with an old client, he will just not include the new transactions but everything else works as before.  Or, to the contrary, will his blocks be rejected by the rest of the network as invalid because he didn't update his client?

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?  Note that I couldn't pull the latest source because of dependency hell.  I'd insert lets say 20 lines of code into one place that exists unchanged in the last two years of the source.  But I wouldn't make 20 different changes in 20 places that can't be located in my copy because they exists only in recent code anyway.  Note that I'm not interested in adding experimental P2SH functionality or anything.  This question is strictly about adding the vote cast, nothing else.  What change(s) are necessary for that?

Thanks for taking your time to answer!

Ad (1). The old miners will do just fine except they won't understand and hence won't validate the new multisig transactions.
Ad (2). Analyze Luke's patch

Thanks for the info.


I can apply the init.cpp patch.  But my codebase has no "COINBASE_FLAGS", so the other two patches don't apply.  Is there a way to cast the vote without backporting COINBASE_FLAGS?

The vote is a coinbase flag, so no.  Check Luke's recent posts, I could have sworn his post about that patch had some sort of instructions on applying and building it.

Hello? You can just click the "Quote from: Luke-Jr..." link I posted to see his whole post jetmine  :)

Yes. Old solo mining clients will produce perfectly valid blocks, unless they've been hacked to mine "non-standard" transactions.

There is a small risk that somebody ELSE will produce an invalid block, old solo mining clients will think it is valid, and will try to mine on top of it.  But that's a small risk because we'll wait until a super-majority of the network supports p2sh before starting to reject any p2sh transactions.

So worst case scenario would be:

+ Somebody with a hacked bitcoind mines a block containing a valid-under-old-rules, invalid-under-new p2sh transaction.
+ Old miners try to build on it, but the majority of the network rejects it (there's a short block-chain split).

If an attacker could target just the p2sh-supporting nodes and denial-of-service enough of them to get p2sh support below 50%, then there could be a longer block-chain split. If you do the math, that's not as easy as it sounds (if p2sh support is at 80%, you'd have to knock out 60% of the supporting nodes-- 20% of the original network would support, 20% wouldn't...).


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.

Why can't we just enable the feature automatically and permanently only after it's safe as I suggested here (https://bitcointalk.org/index.php?topic=60433.msg710331#msg710331)?

Because it is NOT a feature that can be toggled on and off. We're talking of protocol-level changes.
Why does trust in the core devs seem to have evaporated out of a sudden?
I'm hearing newbie members with a dozen or so posts raise the BIP16/17 issue... that's straight laughable.

Did you actually read what I wrote? What I wrote is to implement the feature in such a way it's irreversibly enabled for everyone at the same time, only after the majority of hashing power supports it instead of a fixed date. Similarly as the feature I described in this proposal (https://bitcointalk.org/index.php?topic=60911.0) (which nobody reviewed or commented yet).

edit: The trust in the core devs seems to have evaporated because there isn't a consensus between them. They should choose between 16 or 17 and we'll be in peace again.

They did choose. But then Luke put out a last minute proposal...

And a FUD PR campaign...  :)

... as a result of which every second newbie I see appears to be running circles in a panicked state screaming "OMG, the OP_P2SH is upon us! We're too young to die like this! Our blood is on your hands, Gavin!".
Quite ludicrous actually, considering the extremely technical nature of the dispute between the advocates of the two competing implementations.

When I fire up the log console, that's what I see:  ;D

Notes:
Any similarities in nicknames are purely coincidental
* user appears to be slightly lost on the technicalities here but it's the good intentions that matter :P

1) people who are new on the forum are not necessarily new to bitcoin
2) there were some serious allegations against Luke who is one of the developers (using his pool for attacks, generating invalid blocks probably due to his modified client)

Never said they necessarily are.
But it isn't even near enough to be familiar with bitcoin client's source code to take side in this discussion.
Not only would one have to have studied the transactions scripting code diligently, extensive formal algorithm analysis would have to be performed.

I'm not one of the devs, not having put in the time and labor required for code analysis I don't feel qualified to support either side, but my stance on the subject is:
for the core developers to ask the general forum population about OP_P2SH and OP_CHC would not be unlike asking directions of a pig.

Mind you, that's precisely what Luke himself admitted his poll showed. Nearly 30% of the voters didn't want multi-sig at all, didn't see an issue in doing multi-sig the old way using insanely long addresses, or preferred to go with the DOA OP_EVAL.

I'm fully aware of the nature of the allegations. The fact that someone is a great coder doesn't tell you anything about their ethical or moral stance, now does it?
Still, without Luke Bitcoin would be inferior to what it is today. That includes miners (cgminer comes to mind) as well.
He is committed, no doubt about that.

Just observe the insane levels of drama brewing here... and laugh at it as I do.

I'm not a big fan of Luke's attitude or the way he has handled himself during the BIP16/17 dispute, but I do trust that he is absolutely committed, in his own way, to the health of the bitcoin system.

There are no allegations that he's used his pool to attack various merged mining chains, just facts.  He usually shows up in the threads in person to take credit for crushing them.  But he only does this to systems that he considers scammy.  So far, I agree with him, and I even bumped his pool up in my failover priority list because I support his efforts in this area.  However, I did disable his pool entirely in my system until the BIP16/17 thing is resolved, because I prefer P2SH over CHV.  Once that is resolved one way or the other, I intend to return.

His pool mines non-standard transactions, but not invalid ones.  The standard client will refuse to process (create, process or mine) transactions that don't fit the standard templates, and for very good reason, but that doesn't make other transactions invalid.  If they were really invalid, the rest of the network would have rejected those blocks instead of building on them.  People that want or need non-standard transactions have to take extra effort to get their transactions to his pool, and when they do that, they have to know that they are doing it without the safety net of the standard transaction checks.

Also, not every forum noob is a bitcoin noob, but I'd bet $100 on each and every one of them, and I'd be a millionaire in a hurry.

it doesnt matter if the allegations are true or not - the fact that there are rumors out there makes people reconsider the trust they have given so far.
I do not think any of the developers want to harm or scam the network, but in their strive to improve it they might make mistakes.
Even though i am not familiar with the code. Me and many others here are familiar with the software development cycle and how log each step in that cycle usually takes.
It seems to me that things were rushed regarding the p2sh. Statements "p2sh should be implemented ASASP" are all over the forum.
From my experience so far - beta testing and debugging, after everything was implemented takes at least a couple of months. Introducing major changes to the live client a month after the idea occurred seems too fast to me.
And as far as the vote goes - the developers can and should force any change to the protocol they think is necessary even if the users disagree, because the devs are the professionals in this matter. But if they decided to bring the issue into the forums and ask the users - they should do that properly , and not create a client with a default "i am voting for the change".

Firstly, it's not even a matter of the client application. It's not the users but the pool operators who get to decide as you have to run your own bitcoind to be able to cast a vote.

Secondly, - and this is almost too rich - how else would they be able to motivate over 51% of the user base to enable either of those two if not for the code?
There is no alternative to just putting the auto vote in, really.
Look at how many users neglect to enable wallet encryption which is in their own best interest. The option it there as well.
You want those technically-ignorant users to decide on the future of bitcoin? Really? By means of a drop list or two radio buttons?

Thirdly, 51% of the hash rate isn't a long term solution. The idea is to make as large percentage of the hash rate as possible BIP16-compliant for network efficiency's sake since the old clients won't be able to validate the new-style transactions. Also, the decision to proceed with BIP16 had already been made by the core dev team then Luke proposed BIP17 out of the blue.

Some careful thinking over this matter is preferable to just pouring out hectoliters of unwarranted criticism at the devs because their decision is (or has been manipulated to look as if it is) unpopular.

I am running my own bitcoind as everyone should (unless restricted by specific hardware) .
I am mining on p2pool,  so I have my own vote.
So it's all luke's fault again? :)
I will always update my client to the last avaliable version to keep the network stable. It has nothing to do with the discussions that started here. The devs have the final vote, but the users are free to object.

You need to go read the threads, the IRC logs and the mailing list archives again if you think that this popped up on 30 days notice.  The magic word for today is October.

I was referring this:

https://en.bitcoin.it/wiki/BIP_0016

That's what most people see. I don't read the irc logs or the mailing lists.
Edit:
when was this change implemented on the test network?

Again, the vote has come and gone. That's what's frustrating. The new clients do NOT say "i am voting for the change", but rather, "I am ready for the change". Just a few weeks ago P2SH had complete consensus among the developers. Now, however, this is being painted as a conspiracy, forcing the development process to spill out into the general public... over semantics. I kid you not, but to the end user, BIP 16 and 17 are exactly the same. In fact, most developers don't need to care. The only people this decision affects are the people who work with the scripting system.

I use to be against BIP 16 (P2SH), but Gavin's understanding of it, along with the fact that this is how it should have been done in the first place (ScriptSig should really have originally been just a script hash in Satoshi's initial design) changed my mind.

Good for you, congrats. I'm running my own too.
p2pool? Even better for you and the whole bitcoin universe. *big hug*

Let's not call it anyone's fault. It's nigh impossible for anyone outside the core dev team to tell apart the actual implementation merits from devs merely clashing their egos and stretching their muscles.

Luke's code implementing op_chc looks gorgeous (as I said, he is a brilliant programmer) but not only did it appear very late in the game but also having a look at the C implementation is far from being able to spot any potential flaws (including lethal flaws able to kill Bitcoin altogether).

Also, mind you the devs are actively debating the future of BIP17 and might opt not to proceed with BIP16 if they find Luke's proposal significantly better (and they can't agree it actually is any better).

You can't stop any programming project and derail its time table just because one of the programmers has come up with some arguably better code which will require a lot of additional work and delays. The devs want multiple signatures enabled yesterday, even should the resulting code be less elegant.

This is exactly my problem...
They wont get fired if they delay the schedule by a few months or even a year.
This change is supposed to stay in the system for as long as it exists. Not using a possibly better solution that will need to work for decades because you didn't want to delay the schedule by a few months sounds silly to me.

Another concern i have is compatibility. some people will be using an older client. If you asked me, first i would have released a client that can properly validate P2SH but will refuse to create such transactions, and only a few months later release a client that can actually create such transactions. This way the clients will have to be 2 versions and about 4-6 months behind the current version to be affected in any way by this change.

Seriously man, go do some reading.

The master branch on github can process P2SH transactions today, but doesn't create them.  There will need to be huge changes in the wallet and UI before any P2SH transactions can actually be created except through custom tools and/or hand crafting.

can the 0.5.2 client validate p2sh transactions?
who the hell installs their client from the latest github source?

Edit:
consider the following scenario:
2 non techie bitcoin users who dont read the forums. user A has 0.6.0 user B has 0.5.2
User A buys something from user B
User A: "i have sent you the money" (using p2sh)
User B: "no you didnt. i dont see anything in my wallet. I am doing a charge back/recall of my product"
now both users think the other is a scammer...

Think October. No, not The Hunt for Red October. Last October. The devs have been at it since last October!

then the wiki is misleading...
It states that P2SH was created on Jan 3 ( I assumed it wasnt tested on testcoin before that time)
I am not talking about months of development - i am talking about months of practical testing on testnet

Ok, I'll be more precise for you:
The devs have been working at multi-sig implementations since last October.
The previous implementation, specified as BIP12 (OP_EVAL) nearly made Bitcoin self-aware as it unintentionally made the Script language turing-complete  ;D
Unwilling to risk another Skynet, the devs quickly shot, staked, and buried OP_EVAL, and recycled the sanitized code as BIP16.
Better now?

EDIT::Seriously, don't hold this against me but the fact that I need to explain all of this to you means that we probably shouldn't have wasted time on this conversation.
         You're accusing the dev team of rushing the code without being aware of the time table? Come on...

EDIT::To make up for their total lack of purpose, I tried to make my posts at least enjoyable to read - hence all those bad jokes.

As soon as the miners are ready, the plan is to release general binary updates. The only reason that hasn't been done yet is because the only people that matter for supporting this are the big pools, and they all know how to compile from source.

This step is not possible without a bunch of manual work. User B would have had to provide a P2SH address, and those don't even officially exist yet.

nope
it still means that BIP16 is less than a month old

Yes, this was tested (https://bitcointalk.org/index.php?topic=56969.msg697626#msg697626) on the test network, after being tested on a virtual test network.


0.5.2 does not include P2SH.  To register a vote for P2SH, you have to go out of your way to do it by building from git.  The presence of /P2SH/ in a coinbase can be taken as pretty strong evidence of two things.  First, that a mining node with a decent amount of hashing power is capable of mining blocks with transactions that include P2SH, and second that someone actually intended to make their support public.  For a few days, it was possible to grab the master branch and compile it with P2SH support without knowing, but that was a while ago, and like you said:


The answer is "almost no one", and that is the whole point.  If enough of the hashing power goes out of their way to include /P2SH/ in their coinbases, we are ready to move forward.  Otherwise, there is no point working on the other stuff that will be needed before it can actually be used.

And I'm going to merge two replies that popped up while I was typing this. 



Please, please, please go read up on this before you ask anything else.  This is a complicated topic, and there is no shame in not knowing how it all works, but your posts strongly suggest that you also haven't bothered to do even minimal research on the subject.  Your question about the potential scam is pretty troubling, since user B is the scammer, so it doesn't matter what version of the client he is using, and user A will see the payment as plain as day.

ok. let me state my concern more clearly:

my concern is not about the technical details of the BIPXX. the devs will be far more capable than me in pointing out possible issues.
I have no intention of becoming a bitcoin dev or spending hours/days to got through all the nuances of the existing and proposed code. That's the dev's job.
my concern is that it is a major change and it was tested for less than a month on the test network.
my concern is that there might be a better solution that is discarded due to the release schedule, without getting the deserved attention.

I have suggested a way to make sure that any changes to the client will go smoothly even if a dev misses some specific issue which might arise. This decision is totally up to the devs. i just wanted to point out that the option exists.