2 questions about this P2SH thing

[jetmine]

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!

[1714152734]

1714152734

[1714152734]

1714152734

[1714152734]

1714152734

[1714152734]

1714152734

[jake262144]

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

... I have written code that allows you the freedom to vote for (-p2sh) or against (-nop2sh):
    https://github.com/bitcoin/bitcoin/pull/755
You can apply it to your bitcoind code like so:
    curl https://github.com/bitcoin/bitcoin/pull/755.diff | patch -p1

[jetmine]

Thanks for the info.

Ad (2). Analyze Luke's patch

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?

[kjj]

Thanks for the info.

Ad (2). Analyze Luke's patch

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.

[jake262144]

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

[Gavin Andresen]

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.

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...).

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.

[DiThi]

Why can't we just enable the feature automatically and permanently only after it's safe as I suggested here?

[jake262144]

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.

[DiThi]

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 (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.

[Maged]

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...

[kjj]

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... 

[jake262144]

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:  

Code:

...
! Newbie1(23): "This is the day Bitcoin was murdered by op_p2sh."
% Newbie1: morale broken: running away
% L337Ha><orMa457er(2): morale broken: unconsciousness
...
! BTCn00b(42): "Why did Gavin killed us all?"
% BTCn00b: morale broken: running away
...
! MasterOfBitcoins(8): "Luke the Prophet is right, I'll fight against op_chv* to my death. You have my bow!"
% MasterOfBitcoins: morale broken: berserker
# thread started on subject: "...and one bent tuba." in "off-topic".
console dumped to file: lulz.txt

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

[Costia]

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.

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)

[jake262144]

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.

[kjj]

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.

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)

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.

[Costia]

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".

[jake262144]

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.

[Costia]

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.

[kjj]

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.

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.

[Costia]

I was referring this:

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

 BIP: 16
  Title: Pay to Script Hash
  Author: Gavin Andresen <gavinandresen@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 03-01-2012

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?