2 questions about this P2SH thing - page 2.

jake262144

full member

Activity: 210

Merit: 100

Quote from: kjj on January 24, 2012, 08:54:49 PM

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: Grin

Code:

...
! Newbie1(23): "This is the day Bitcoin was murdered by op_p2sh."
% Newbie1: morale broken: running away
% L337Ha>...
! 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 Tongue

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: Maged on January 24, 2012, 08:14:21 PM

Quote from: DiThi on January 24, 2012, 06:39:31 PM

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

Maged

legendary

Activity: 1204

Merit: 1015

Quote from: DiThi on January 24, 2012, 06:39:31 PM

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

DiThi

full member

Activity: 156

Merit: 100

Firstbits: 1dithi

Quote from: jake262144 on January 24, 2012, 05:50:45 PM

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.

jake262144

full member

Activity: 210

Merit: 100

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

full member

Activity: 156

Merit: 100

Firstbits: 1dithi

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

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

Quote from: jetmine on January 24, 2012, 07:04:02 AM

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

Quote

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.

jake262144

full member

Activity: 210

Merit: 100

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

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: jetmine on January 24, 2012, 01:37:26 PM

Thanks for the info.

Quote from: jake262144 on January 24, 2012, 01:01:51 PM

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.

jetmine

newbie

Activity: 53

Merit: 0

Thanks for the info.

Quote from: jake262144 on January 24, 2012, 01:01:51 PM

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?

jake262144

full member

Activity: 210

Merit: 100

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

Quote from: Luke-Jr on January 13, 2012, 01:13:36 PM

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

newbie

Activity: 53

Merit: 0

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!

Topic: 2 questions about this P2SH thing - page 2. (Read 2936 times)