MultiSig Deployment has been delayed! and OP_EVAL is DEAD.

[finway]

I guess.  

[adamstgBit]

Don't rush them

what is this anyway 

[finway]

Don't rush them

what is this anyway 

Yeah, nobody care about it until half month before that.

[finway]

Still too few developers, i guess.

[finway]

I don't think it is something I would use right now but I do see it being a nice feature.

Is there a way to donate to "development" ?

Yeah, i guess i start to agree with Gavin's idea,
we should form a organization to hire a team for testing, bug finding,
if we do care about the development.

No just wait until just before the deadline,
some guy don't even have a single Bitcoin ,and dont' appreciate bitcoin,
find a bug and kill the whole idea.

We are delayed by ourselves.  

[finway]

I think the development team should work like FOMC of FED?
Relase some "Official" informations ?  But Bitcoin is a decentralized Currency,
This is a contradiction But decision was made by a small group of people.

[genjix]

Calm down. All the developers in the world won't help you. This is a complex problem.

Unless more happened in the last 8 hours, we were discussing before dropping OP_EVAL as an explicit instruction.

This simply means that there is a new template transaction type which bitcoin detects and handles gracefully. The top item in the input script is EVALuated without there actually being an OP_EVAL there to tell it to do that.

There is an online meeting today:
https://bitcointalk.org/index.php?topic=56376.0

People are free to join, but I guess it is more for developers to discuss the issue than explain it to the community :p

[finway]

Calm down. All the developers in the world won't help you. This is a complex problem.

Unless more happened in the last 8 hours, we were discussing before dropping OP_EVAL as an explicit instruction.

This simply means that there is a new template transaction type which bitcoin detects and handles gracefully. The top item in the input script is EVALuated without there actually being an OP_EVAL there to tell it to do that.

There is an online meeting today:
https://bitcointalk.org/index.php?topic=56376.0

People are free to join, but I guess it is more for developers to discuss the issue than explain it to the community :p

But even if this new templates are agreed or approved,
it still need a new cycle of "Coding、Testing、Deploying",
and i guess maybe 3months later ?

I'm just curious, this OP_EVAL idea was brought up about 3months ago,
where are you developers?
Now right before deployment，you someguy bring up nonsense issue "impossible for Script Static Analysis".

 

[Vandroiy]

No FUD please; is there a problem or not? OP_EVAL itself never made much sense to me anyways, so please only spread panic if a targeted feature gets lost.

Right now, we mostly need some kind of multisig. From all I understand, most usage cases need either "2 of 2" or "2 of 3" signatures. If the new solution delivers that, I'm content for the time being.

We need the security of multiple keys and trust contracts... I mostly care about the latter. I might need a transaction "we both pay some amount, and we only get it back if both sides agree they still like each other".

[Stefan Thomas]

No FUD please; is there a problem or not?

Russell and I raised some concerns, but we're both happy now with Gavin's latest proposal. Unless someone else comes out with new criticisms at the meeting tonight, I expect that the new proposal will go through. (You can't really call it OP_EVAL anymore, but it does the same thing with fewer bytes and simpler semantics.)

As for what the new proposal is called:

<justmoon> gavinandresen: has anyone thought of a good name for your proposal? (the OP_EVAL alternative with a magic scriptPubKey)
<gavinandresen> justmoon: It needs a good name-- PayToScriptHash is the best I've been able to come up with

So it looks like that's what it's called until further notice. But it really does exactly the same thing as OP_EVAL without the stuff that made some of us uneasy.

For a technical explanation of what this was all about, I can refer you to my summary on the mailing list: http://sourceforge.net/mailarchive/message.php?msg_id=28616889

Edit: Added emphasis.

[finway]

I don't know, i think "Static Analysis" is useless, and without it , still safe.

I am sad that all gavin's work have been wasted! 

[Gavin Andresen]

I am sad that all gavin's work have been wasted!  

Don't be sad-- it hasn't been wasted at all. Most of the work was making multisignature transactions work properly, the OP_EVAL part was a small amount of code (which becomes an even smaller amount of code under the new PayToScriptHash scheme, which is one of the reasons I like it).

And re: new cycle of coding/testing/etc taking 3 more months:  I'm going to propose slipping the schedule by two weeks, which means a "network is fully validating the new transaction types" of Feb 15 instead of Feb 1.

[bc]

I am sad that all gavin's work have been wasted!  

Don't be sad-- it hasn't been wasted at all. Most of the work was making multisignature transactions work properly, the OP_EVAL part was a small amount of code (which becomes an even smaller amount of code under the new PayToScriptHash scheme, which is one of the reasons I like it).

And re: new cycle of coding/testing/etc taking 3 more months:  I'm going to propose slipping the schedule by two weeks, which means a "network is fully validating the new transaction types" of Feb 15 instead of Feb 1.

That sounds fine. Even if we had to slip a month, it's far preferable to the loss of confidence from a bad regression.

[Explodicle]

That title had me worried! If anyone working on multisig wants help from a halfway computer literate enthusiast, let me know! I'd be happy to contribute. Better to take our time and get it right on the first attempt.

[finway]

Don't be sad-- it hasn't been wasted at all. Most of the work was making multisignature transactions work properly, the OP_EVAL part was a small amount of code (which becomes an even smaller amount of code under the new PayToScriptHash scheme, which is one of the reasons I like it).

And re: new cycle of coding/testing/etc taking 3 more months:  I'm going to propose slipping the schedule by two weeks, which means a "network is fully validating the new transaction types" of Feb 15 instead of Feb 1.

Glad go hear that! Thanks,Gavin.

[mcdett]

Couldn't this --> https://en.bitcoin.it/wiki/Active_Bounties fix the problem?  If enough people desire the feature maybe their willing to pay for it?  We need to use this or something more dynamic (http://www.kickstarter.com/) to provide a forum to enable the presentation of value ideas to the btc community, and the allowance of good ideas to be provided real incentive to implement their idea.

There is also a few btc community members who would be happy to leverage some of their btc holdings to provide greater longterm prospects of btc value.

[Stefan Thomas]

Couldn't this --> https://en.bitcoin.it/wiki/Active_Bounties fix the problem?

What problem?

[mcdett]

Couldn't this --> https://en.bitcoin.it/wiki/Active_Bounties fix the problem?

What problem?

MultiSig Deployment has been delayed! and OP_EVAL is DEAD

[Stefan Thomas]

MultiSig Deployment has been delayed! and OP_EVAL is DEAD

The delay is two weeks and I don't think it's caused by a lack of developers. If you think about it, it was caused by "too many" developers getting involved who had problems with the old proposal.

As for OP_EVAL... I can't speak for gavin, but I know in sipa's and my mind OP_EVAL isn't dead. The new proposal doesn't use up an opcode, so if we still want to, we can implement OP_EVAL at a later time - perhaps even using the same code. We just don't *need* OP_EVAL, because we now have a better way (less bytes, easier implementation => no change to EvalScript, static analysis => minimal changes to GetSigOpCount) of moving scripts from the scriptPubKey over to the scriptSig.

[finway]

MultiSig Deployment has been delayed! and OP_EVAL is DEAD

The delay is two weeks and I don't think it's caused by a lack of developers. If you think about it, it was caused by "too many" developers getting involved who had problems with the old proposal.

As for OP_EVAL... I can't speak for gavin, but I know in sipa's and my mind OP_EVAL isn't dead. The new proposal doesn't use up an opcode, so if we still want to, we can implement OP_EVAL at a later time - perhaps even using the same code. We just don't *need* OP_EVAL, because we now have a better way (less bytes, easier implementation => no change to EvalScript, static analysis => minimal changes to GetSigOpCount) of moving scripts from the scriptPubKey over to the scriptSig.

Never mind