The Truth behind BIP 16 and 17 (important read)

[Technomage]

My stance:

http://bitcoinmedia.com/cathartic-progress/

Michael Marquardt (theymos) suggests compiling a list of everyone intimate with the bitcoin protocol to invite to a two-week email discussion. After those two-weeks a vote is taken. It will be the job of the champions of each idea (BIP 16, BIP 17 and no change) to win over the committee into supporting them. If an idea has necessary support, bitcoin clients will be programmed to apply the new rules for 3 months in the future.

I really hope this is the next step.

[Steve]

My stance:

http://bitcoinmedia.com/cathartic-progress/

Michael Marquardt (theymos) suggests compiling a list of everyone intimate with the bitcoin protocol to invite to a two-week email discussion. After those two-weeks a vote is taken. It will be the job of the champions of each idea (BIP 16, BIP 17 and no change) to win over the committee into supporting them. If an idea has necessary support, bitcoin clients will be programmed to apply the new rules for 3 months in the future.

And the nice thing about this is that if the committee comes to a decision the miners disagree with, the miners aren't bound to actually follow the decision of the committee.  

I posted some stuff about using the Condorcet method in replies to the article.

[Andrew Vorobyov]

I just want to underline that if miners will not agree with it they will be responsible for future of Bitcoin.

Please, make sure that in the long run we will find solution... but it can cost us chain forks (blood and revolutions)...

I hope we can stay away from it and keep unity... because otherwise things can go pretty nasty... I really would think twice before submitting myself to be responsible for BTC's future..

BTW, I like Tyco's approach... if he had taken any side it will be irresponsible for him...

[EhVedadoOAnonimato]

Thanks gengix for the article.

I agree with Tycho and Mike Hearn. There is no urgency in this. The risks are high when compared to the small feature improvement.

Huge addresses are not a major problem. If people can get along with huge URLs, there's no reason to believe they would be lost with large addresses. Even if an address is thousands of chars long, shortening services could come along and provide a short URL that you can put into those QR codes again.
And transaction fees are and will remain very cheap to the end user for several years yet. People actually argue they will remain low forever, and that the main financing to mining will come from other sources. Even if that's not the case, there's plenty of time to do this calmly.

Why not just let every potentially chain forkable change to be made when the block size limit is increased/removed, since that will have to happen one day anyway?

[cbeast]

Huge addresses can make difficult to read QR codes. They become harder to scan with a camera phone and even print clearly. Just an added observation.

[EhVedadoOAnonimato]

Huge addresses can make difficult to read QR codes. They become harder to scan with a camera phone and even print clearly.

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

[da2ce7]

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

That is the problem... it takes up extra space in the chain... where the sender pays the fees; not the spender.

This is bad; as say mtgox would only except 'plain' bitcoin addresses.

[EhVedadoOAnonimato]

As do huge URLs. People would just use a shortener, as I suggested on my post above yours.

That is the problem... it takes up extra space in the chain... where the sender pays the fees; not the spender.

And transaction fees are and will remain very cheap to the end user for several years yet. People actually argue they will remain low forever, and that the main financing to mining will come from other sources. Even if that's not the case, there's plenty of time to do this calmly.

[Luke-Jr]

Huge addresses are not a major problem. If people can get along with huge URLs, there's no reason to believe they would be lost with large addresses. Even if an address is thousands of chars long, shortening services could come along and provide a short URL that you can put into those QR codes again.

I don't think it's a good idea to encourage people to trust URI shortening services with their money.

[EhVedadoOAnonimato]

If they are already trusting a service similar to an eWallet to hold half the keys.... but yeah, you have a point, shortening services wouldn't work in most cases. But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

[Atheros]

But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

If we don't fix it soon, it will never get fixed. And it needs to get fixed because it will be an enormous problem several years from now. Proper scrutiny and testing is certainly necessary- but these changes are urgent.

Protocol changes are early or never. And never is very very bad.

[Luke-Jr]

But still, big addresses and transaction fees are not that big of a problem to provoke all this rush and heated discussions.

If we don't fix it soon, it will never get fixed. And it needs to get fixed because it will be an enormous problem several years from now. Proper scrutiny and testing is certainly necessary- but these changes are urgent.

Protocol changes are early or never. And never is very very bad.

There are much more important fixes that need to be made for Bitcoin to scale, and they are hard-forking.

[Atheros]

Like the maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000)?

Maybe this is naïve, but I'm personally fine with that being taken care of a little later- the very fact that it *must* be done means that it actually will get done. And hopefully by that point we can take care of a few other things on the hardfork wishlist.

[2_Thumbs_Up]

Huge addresses can make difficult to read QR codes. They become harder to scan with a camera phone and even print clearly. Just an added observation.

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

What is the added value beyond shorter addresses for complex transactions? Because I don't see that as very important.

I think it's important.  An address doesn't have to be a hash of anything…an address could be the entire script that you want someone to send coins to.  However, that would be rather unwieldy and there has been considerable investment in the notion of a bitcoin address being a relatively short thing.  Both investment in terms of software and investment in terms of people learning and understanding bitcoin.  To start passed around very long addresses would be rather confusing I think.  It also has the drawback of revealing more about the destination script than is necessary.

P2SH is the way that bitcoin should have been designed from the beginning IMO.  Outputs of transactions (scriptPubKey) should have always been just a hash and the validation always been that a script hashes to that value and executes successfully.  Using long addresses would be moving in the wrong direction in my opinion.

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

[Atheros]

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

This would still be the data one would need to copy and paste. They would still be called "Bitcoin addresses" by everyone except perhaps the developers themselves. They should be as short as possible. Also, all of that data is necessarily going to be stored in the blockchain- much of it forever and ever.

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Yes, this is my impression. The fact that we have an old blockchain isn't the problem, it is the fact that we would have old clients. They would need to upgrade.

[2_Thumbs_Up]

But RFID tags will most likely be a good competitor to QR codes as NFC becomes standard in smart phones, no?

This would still be the data one would need to copy and paste. They would still be called "Bitcoin addresses" by everyone except perhaps the developers themselves. They should be as short as possible. Also, all of that data is necessarily going to be stored in the blockchain- much of it forever and ever.

I agree with those points, I just don't think that QR codes will stay around forever so that part shouldn't really be a factor in determing the future of bitcoin as far as I'm concerned.

Am I right in my understanding of the issue if I think that the problem arises from trying to implement P2SH and keeping backwards compatibility? If P2SH had been the way bitcoin works from the beginning then it would be fine, but since we now have an "old" block chain to think about the solutions become hackish?

Yes, this is my impression. The fact that we have an old blockchain isn't the problem- it is guaranteeing that enough people upgrade.

Ok. I'm not a dev so I'm very cautios in suggesting anything. This is more out of curiosity and for understanding. But would it be technically possible to start over from scratch with a new block chain and altered protocol that allows P2SH in a clean manner and put all the current owners of bitcoins in the genesis block?

I'm just a user of bitcoin so I know my voice doesn't have the most weight. But I do see the value in the features that P2SH provides but hackish solutions still make me very wary, and I'm probably not the only one. So if it's at all possible to implement this in a clean manner that would put a lot of my worries to rest, even if it would be more cumbersome to transition.

And I don't really want to go into the dangers of such a transition with the merkle tree and whatever. I'm just wondering if it's technically possible, or if a clean implementation of P2SH is incompatible with the current adress syntax even with a new block chain.

[[Tycho]]

Also I would like to say that at least partially all this mess is caused by the opcodes that Satoshi disabled more than a year ago.

I think that multisigs with short addresses can't be implemented without P2SH because OP_CAT op is disabled. May be.

[Atheros]

RE: 2_Thumbs_Up

That new 'genesis block' would be just as big as the current pruned blockchain, so there is no point in doing it that way. Luckily there is no need: clean and simple P2SH would be easy to do with the current blockchain and transactions. The only challenge would be, apparently, the network-wide upgrade process.

[westkybitcoins]

At the risk of rehashing a settled issue, I have a stupid question:

It is already cryptographically possible to have two or more devices each have access to a portion of a private key, and be able to combine these portions to spend funds in such a way that no device gains access to any more of the private key than it already had, correct?

If this is the case, I'm wondering why it's considered mission-critical to implement scripting for multisig and for extra security measures in general by altering the protocol, rather than letting the owners of the private keys take responsibility for securing them and preventing unauthorized spending.

[Luke-Jr]

It is already cryptographically possible to have two or more devices each have access to a portion of a private key, and be able to combine these portions to spend funds in such a way that no device gains access to any more of the private key than it already had, correct?

AIUI, no.