Deadlines and moving forward (BIP 16/17 support)

[Vitalik Buterin]

Is there any problem with just keeping both BIPs open until one is decided on?

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

[1715594934]

1715594934

[1715594934]

1715594934

[1715594934]

1715594934

[interlagos]

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

I can agree to this if there will be a mechanism to preserve "wealth" of current network and transfer it into the new one..

Really, can you, developers, come up with a script that does this? Like CTRL-C CTRL-V

I think there have been a precedent like this in one of the alt-chains starting with S
They suspended 1.0 chain and somehow transferred all wealth into 2.0 chain which had new rules and its own genesis block.
So it should be possible at least theoretically.

[gmaxwell]

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position.

[makomk]

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position.

Some of them may be less important than you think. For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them.

[flower1024]

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

+1

[gmaxwell]

Some of them may be less important than you think.

I don't think any particular issue is the end of the world— but the representation that we can just use big addresses and it's no big deal is ignoring that there are other issues. I know you know about some of them. But I don't believe most people saying "oh, big addresses are no big deal" do.

For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them.

Interesting thought, I hadn't considered that possibility. But "We can handle longer ones" isn't the same as "don't care" by doing that the minimum length for a 2of2 simple secured wallet, pretty much the simplest case, probably won't fit in a tweet anymore (for example), they won't fit in the small QR codes anymore, etc.

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc.   Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.

[eldentyrell]

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

They suspended 1.0 chain and somehow transferred all wealth into 2.0 chain which had new rules and its own genesis block.

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

[makomk]

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc.   Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.

Nope, no magic solutions to either of those sadly - there's a reason that I supported the idea of P2SH back in the OP_EVAL era before the whole thing turned into a circus, and in fact Coiledcoin started off as my personal testbed for playing with it with all the mainnet checks still in operation. Something that works is better than something that might work eventually though.

[Killdozer]

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

Seems like even a possible solution to the everbloating blockchain problem.

[jtimon]

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

Maybe that should be here for later forks, but as far as I know neither BIP 16 nor 17 need a fork like that. Old clients will remain compatible.

If the change is going to be a big one anyway and will require a client upgrade why not...

It does not, in fact— Yes, it requires a client update to make use of the new functionality, but old nodes will happily continue to validate things.  It's hard to express how critical this is distinctly. Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that things were done right, the validate them for themselves.

[Gavin Andresen]

OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

It is time to call it settled and move on to bigger and better things, like what protocol to use when a client needs to gather signatures (REST? JSON? http? https? something else?).

[Technomage]

OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

+1

That vote seems to indicate a strong preference for BIP16. Now it's up to the miners to do what is right, as far as I know slush is still supporting BIP16 right? Don't forget to add his pool to your signature.

[blueadept]

...as far as I know slush is still supporting BIP16 right? Don't forget to add his pool to your signature.

Bitcoin.cz is slush's pool.

[eleuthria]

BTC Guild blocks will be containing BIP 16 support, hopefully between February 10 and 12.

[Technomage]

BTC Guild blocks will be containing BIP 16 support, hopefully between February 10 and 12.

+1

This is great news.

[Balthazar]

We successfully migrated to git snapshot of bitcoin-0.5.1 with P2SH/CHV patches today.

Waiting for block...

[P4man]

Ill throw in my 2 cents, even if Im too late

In a democracy, on most complex financial/economic/political/etc issues, ordinary voters "are not qualified" either. But they do vote, as they should; they vote representatives who are supposed to know these issues better. I think the same goes here, I may not understand all the technical ins and outs of BIP16, but I know what its about and to put it very simple, to me it boils down to, do I trust Gavins judgment above Lukes?
I think thats actually quite a reasonable approach to follow. You can decide to put faith in a pool op, or actively decide which pool you will join that supports you POV. Its almost like political parties .

To continue my parallel with democracy; non voters dont get counted. I dont see why we should count them here (unless maybe there was a way to vote "undecided"). This process is new, so we should give it some time otherwise  it may cause a bit of a panic initially, but if you make votes binding and ignore the non voters, Im sure quickly miners and pools will get more involved and more interested in whats going on to make sure they cast the right votes. If they dont, their votes are simply ignored, i see no reason to allow non voters to halt the development of bitcoin.

[ThePok]

Thats a great Idea!

People that dont Vote dont care, are not infomrmed, so they dont count. People that did make a desicition sure did think a while about it. But we need more than the currrent 2 Options:

Vote Pro BIP16
Vote Pro BIP17
Vote None Yet

All other Blocks without vote dont count.

But theres a Problem too, if to manny miners dont care for the Wnner of the Vote, a Win of the Votingprocess didnt help

But Votingprocess is much faster

[Rassah]

In a democracy, on most complex financial/economic/political/etc issues, ordinary voters "are not qualified" either. But they do vote, as they should; they vote representatives who are supposed to know these issues better.

LOL! As long as those representatives are not "East-coast Educated Elites™" and are good at "sitting down to have a beer with" 
Because economics and finances that involve complicated mumbo jumbo are just liberal lies in disguise, and not good, down-to-earth, Reagan-style, Amuhrican economics 

[runeks]

To continue my parallel with democracy; non voters dont get counted. I dont see why we should count them here (unless maybe there was a way to vote "undecided").

As far as I understand, we need to count the vote of the non-voting miners, because we need the support of the miners for PS2H to work. That's why we're waiting for over 50% to actively proclaim that they support PS2H transactions, and that they will be including them in blocks when these transactions start to appear.