Old P2SH debate thread

[rjk]

I do think changes should be avoided at all cost's, UNLESS ABSOLUTELY NECESSARY!  I understand there was a change the HAD to be made because of an actual flaw, that is/was appropriate.

What change are you fearing? AT THE VERY WORST, all that can happen is that new (OP_EVAL/P2SH/CHV) transactions have "something bad" (if anything?) happen to them. Existing transactions aren't changed and do not get affected by this.

This issue can be ameliorated in so many other ways, and is, that folks should question it a little more than they are.

Do pray tell, how? What are your significant contributions towards mitigating this issue?

I am not concerned about one pool effectively preventing the change by not voting for it and that is why I am mining there full time right now.  And if Tycho did start supporting BIP16 and the implementation was NOT a done deal I would mine elsewhere until it was implemented or defeated, granted at that point it wouldn't really make a difference except clear my conscience if things did go awry because of one of these multi-sig schemes.

You seem to have an irrational fear of a multi signature transaction type being widely implemented and made useable by a larger segment of users. Why?

I am much more concerned with the Bitcoin community trying to strong arm and badger a pool op into doing what they want and effectively take away my voice of dissension in the process.  That is very troubling to me.

This is certainly annoying (at best), but it isn't the end of the world. He is doing a great job of ignoring everyone

[1714030237]

1714030237

[1714030237]

1714030237

[1714030237]

1714030237

[os2sam]

I do think changes should be avoided at all cost's, UNLESS ABSOLUTELY NECESSARY!  I understand there was a change the HAD to be made because of an actual flaw, that is/was appropriate.

What change are you fearing? AT THE VERY WORST, all that can happen is that new (OP_EVAL/P2SH/CHV) transactions have "something bad" (if anything?) happen to them. Existing transactions aren't changed and do not get affected by this.

When I started with Bitcoin all I wanted to do was solo mine with a mid range GPU and just check my wallet 2 or 3 times a year.  That didn't work out.  But if it had worked out that way and a multi-sig was implemented while I had an old bitcoind running then I would have risked loosing my coins.  I think there are several people in that boat right now.  Bitcoin users shouldn't be forced to keep up on all of this minutia just to make sure their coins and transactions are protected.

This issue can be ameliorated in so many other ways, and is, that folks should question it a little more than they are.

Do pray tell, how? What are your significant contributions towards mitigating this issue?

I have take steps to protect my wallet and network.

I am not concerned about one pool effectively preventing the change by not voting for it and that is why I am mining there full time right now.  And if Tycho did start supporting BIP16 and the implementation was NOT a done deal I would mine elsewhere until it was implemented or defeated, granted at that point it wouldn't really make a difference except clear my conscience if things did go awry because of one of these multi-sig schemes.

You seem to have an irrational fear of a multi signature transaction type being widely implemented and made useable by a larger segment of users. Why?

I have a fear of fixing things that haven't been demonstrated to be broken.

I am much more concerned with the Bitcoin community trying to strong arm and badger a pool op into doing what they want and effectively take away my voice of dissension in the process.  That is very troubling to me.

This is certainly annoying (at best), but it isn't the end of the world. He is doing a great job of ignoring everyone

And why is he ignoring everyone?  Because he has nothing to say on the subject or because of retribution?
Sam

[os2sam]

And if Tycho did start supporting BIP16 and the implementation was NOT a done deal I would mine elsewhere until it was implemented or defeated, granted at that point it wouldn't really make a difference except clear my conscience if things did go awry because of one of these multi-sig schemes.

I guess it's time to consider switching?

Tycho has told me that the deepbit pool will support BIP16 as soon as he's able to merge and test the changes, which will put support at well over 55%

Maybe we will see a mass exodus from deepbit now? Or did you guys have a pool meeting?

Well I wasn't invited to a meeting, strangely enough.

But it sounds like a done deal or is it not?
Sam

[rjk]

When I started with Bitcoin all I wanted to do was solo mine with a mid range GPU and just check my wallet 2 or 3 times a year.  That didn't work out.  But if it had worked out that way and a multi-sig was implemented while I had an old bitcoind running then I would have risked loosing my coins.  I think there are several people in that boat right now.  Bitcoin users shouldn't be forced to keep up on all of this minutia just to make sure their coins and transactions are protected.

I am starting to understand your perspective. However, it is flawed! This protocol change CAN NOT AND WILL NOT erase old bitcoins, NOR will it make them unspendable. You are not at risk of losing ANY of your bitcoins, whether you are running an old client or a new one.

This issue can be ameliorated in so many other ways, and is, that folks should question it a little more than they are.

Do pray tell, how? What are your significant contributions towards mitigating this issue?

I have take steps to protect my wallet and network.

I meant mitigating it for the larger userbase, not just yourself.

[muyuu]

What are the deadlines involved? (if there are any - also, a reference link to keep track of that would be appreciated, if it exists).

[os2sam]

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

[rjk]

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

Eheh, that was me, I don't need a refund though.

[os2sam]

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

Eheh, that was me, I don't need a refund though.

Which one was it?

[muyuu]

In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin.

What trash talk? criticism isn't trash talk. Some people disagree about BIP 16 being the right step to take, that's all. Having disagreement isn't necessarily bad for Bitcoin. Letting personal issues take over technical arguments is worse for Bitcoin IMO.

I don't know enough about the protocol to make a technical argument. Maybe in a few months time when work allows I will. But know I'd feel a lot more comfortable about the future of bitcoin if these issues were discussed in a civil way and focusing in the technical aspect...

[rjk]

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

Eheh, that was me, I don't need a refund though.

Which one was it?

0.1 BTC to the "shut up" address, is that what you mean?

[Luke-Jr]

FWIW, I had intended to give up and withdraw BIP 17 last week, but decided against it due to multiple people PMing me saying they read the BIPs and agree. So I'm giving it a bit more time in hopes the tide turns enough that we don't get stuck with BIP 16.

[os2sam]

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

Eheh, that was me, I don't need a refund though.

Which one was it?

0.1 BTC to the "shut up" address, is that what you mean?

Yep
Thanks,
Sam

[DavinciJ15]

After reading this thread it's clear to me we need to have this additional validation rules that apply to the new transactions to attract more users and add security to bitcoin network.  Each method has it's risks and different pros and cons but none of them are perfect.

As a software developer that has a VERY VERY basic understanding of each method and not fully sold on P2SH or Luke-jr's CODEHASHCHECK, if I had a gun to my head I would select CODEHASHCHECK based on what I have read in this thread.  The only reason I can come up with to support P2SH is because Gavin Andresen is not arrogant and that is not a valid reason.

I am not married to any solution and if I wanted to decide on a particular solution, I would need to study the bitcoin protocol a lot more before I could make well educated choice.

From what I can tell the risks are the same and the implementation of both methods can be criticized and considered "Bad" for various reasons.

With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect.  Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered.

That's my 2 bitcents.

Davinci

[Luke-Jr]

With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect.  Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered.

Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network.

[DavinciJ15]

With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect.  Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered.

Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network.

I assumed it was tested on testnet but that's not real world enough.   People need to be able to use it day to day and give hackers time to pick it apart and find a flaw.  Remember the OP_EVAL and the flaw found after it was considered.

I understand you are concerned as I am about the reputation of bitcoin however I just think of all the people telling me bitcoin failed because MTGox was hacked.   I would hate to see the protocol hacked, thus give the haters real ammunition against bitcoin.

Davinci

[Luke-Jr]

With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect.  Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered.

Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network.

I assumed it was tested on testnet but that's not real world enough.   People need to be able to use it day to day and give hackers time to pick it apart and find a flaw.  Remember the OP_EVAL and the flaw found after it was considered.

Perhaps, but in reality the only way to get real day-to-day testing is in the main chain.

[nedbert9]

In my opinion, a scripting language makes sense, even if it's disabled. In any case, enabling a disabled scripting language seems much easier than implementing a scripting language in a currency that didn't support it to begin with.

Sadly this isn't true!  It has do to with the way in which the opcodes in the existing scripting system were disabled -- or perhaps more accurately "never enabled".

Existing clients treat any script containing a disabled opcode as invalid.  As a result, enabling a disabled opcode requires upgrading all clients (miners, exchanges, end-users, etc).

OP_EVAL/P2SH/CHV work because they transfer validity-checking responsibility from the end-user to the miners, resulting in a much smaller set of clients to upgrade.

Hello, Dr. Tyrell.  Love your FPGA work. 

Good comment.  A thought occurs.

In a currency system that functions entirely in software, such a fundamental system, being able to remediate issues, incorporate substantial functionalities should be as close to seamless as possible.

In other words, it seems that there is a fundamental flaw in BTC in that there is no semi-transparent (time frame voluntary, then mandatory) way to move all BTC participants to the next code revision - or  reversion if needed.  Of course, having some segmentation to target updates to relevant components.

These are the growing pains of BTC.  I would hope there are safe, effective and highly coordinated ways to mature the BTC system.

These are the thoughts of a newcomer, but seems these types of problems, and the necessary clunky coordination needed, would frustrate the current average Interwebs user and hinder widespread adoption.