finway (OP)
|
|
January 03, 2012, 03:54:02 AM Last edit: January 03, 2012, 04:47:24 AM by finway |
|
I guess.
|
|
|
|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
January 03, 2012, 03:57:53 AM |
|
Don't rush them what is this anyway
|
|
|
|
finway (OP)
|
|
January 03, 2012, 04:00:11 AM |
|
Don't rush them what is this anyway Yeah, nobody care about it until half month before that.
|
|
|
|
finway (OP)
|
|
January 03, 2012, 04:05:26 AM |
|
Still too few developers, i guess.
|
|
|
|
finway (OP)
|
|
January 03, 2012, 04:10:15 AM Last edit: January 03, 2012, 04:48:07 AM by 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 (OP)
|
|
January 03, 2012, 04:12:50 AM Last edit: January 03, 2012, 04:36:49 AM by 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
Legendary
Offline
Activity: 1232
Merit: 1076
|
|
January 03, 2012, 06:13:39 AM |
|
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.0People are free to join, but I guess it is more for developers to discuss the issue than explain it to the community :p
|
|
|
|
finway (OP)
|
|
January 03, 2012, 06:26:08 AM |
|
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.0People 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
Legendary
Offline
Activity: 1036
Merit: 1002
|
|
January 03, 2012, 02:30:51 PM |
|
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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
January 03, 2012, 04:51:58 PM |
|
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=28616889Edit: Added emphasis.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
finway (OP)
|
|
January 03, 2012, 05:11:36 PM |
|
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
Legendary
Offline
Activity: 1652
Merit: 2301
Chief Scientist
|
|
January 03, 2012, 06:24:14 PM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
bc
Member
Offline
Activity: 72
Merit: 10
|
|
January 03, 2012, 09:26:45 PM |
|
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.
|
"Democracy is the original 51% attack." - Erik Voorhees
|
|
|
Explodicle
|
|
January 03, 2012, 09:34:36 PM |
|
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 (OP)
|
|
January 04, 2012, 02:15:32 AM |
|
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
|
|
January 04, 2012, 04:54:41 AM |
|
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
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
January 04, 2012, 05:07:43 AM |
|
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
mcdett
|
|
January 04, 2012, 05:32:43 AM |
|
MultiSig Deployment has been delayed! and OP_EVAL is DEAD
|
|
|
|
Stefan Thomas
Full Member
Offline
Activity: 234
Merit: 100
AKA: Justmoon
|
|
January 04, 2012, 06:14:17 AM |
|
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.
|
Twitter: @justmoonPGP: D16E 7B04 42B9 F02E 0660 C094 C947 3700 A4B0 8BF3
|
|
|
finway (OP)
|
|
January 04, 2012, 10:27:08 PM Last edit: January 04, 2012, 11:33:34 PM by 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
|
|
|
|
|