Topic: BIP 16 / 17 in layman's terms - page 6. (Read 38982 times)
this is why 1 developer can = 50% of miners
If the miners refuse to switch it doesn't work. The devs can't force anything.
But this would pave light way to transition... If transition itself being questionable enough - miners can reject it... Only after this regular users will need to decide.
Small details what matters... People in order of importance
1st - developers
2nd - miners (poolops)
3rd - users
It will eliminate friction from the process...
Sure, everyone is important in different ways.
The 50%+ only applies to miners though, if one dev out of 1000 convinces the miners the change is good it happens. And as long as there are some users who continue using it then the changes protocol continues to exist as a real/used thing.
I'm so sorry for my English...
People in order of importance who can spot problems in Bitcoin development direction...
People in order of importance who can spot problems in Bitcoin development direction...
Quote
Small details what matters... People in order of importance
1st - developers
2nd - miners (poolops)
3rd - users
1st - developers
2nd - miners (poolops)
3rd - users
Really?
Ok,
1st - Developers - lets say 10
2nd- miners - lets say 100
3rd- users - lets say 0
What was that order again?
If the miners refuse to switch it doesn't work. The devs can't force anything.
But this would pave light way to transition... If transition itself being questionable enough - miners can reject it... Only after this regular users will need to decide.
Small details what matters... People in order of importance
1st - developers
2nd - miners (poolops)
3rd - users
It will eliminate friction from the process...
Developers must vote on this, not regular "miners" ( as long developers are trusted)...
I will split my bounty between all developers involved, does not matter of what BIP will be accepted.
I will split my bounty between all developers involved, does not matter of what BIP will be accepted.
If the miners refuse to switch it doesn't work. The devs can't force anything.
Developers must vote on this, not regular "miners" ( as long developers are trusted)...
I will split my bounty between all developers involved, does not matter of what BIP will be accepted.
I will split my bounty between all developers involved, does not matter of what BIP will be accepted.
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.
Might be a good idea. I think you can talk to him about it. He said he would have more time soon to work on the client again.
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.
I thing the devs should take an opinion poll about changes, but ultimately they should set the deadline and have the final say. Anyone else can start their own fork and start their own volunteer network.
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time.I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I've suggested Coblee to consider BIP17 for Litecoin as an alternative to Bitcoin, let's see if we get anywhere with this.
He might need some help to port and maintain the changes though, if he decides to implement multisig at all.
Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig? I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.
What kind of address length are we looking at with each of the proposals?
BIP 13 (P2SH address format, used by all BIP 12, 16, and 17) addresses are (almost?) always 34 characters, similar to current addresses. The Address wiki page has been ahead of the game for a while now. What kind of address length are we looking at with each of the proposals?
https://en.bitcoin.it/wiki/BIP_0013 for both
dont know what exactly the length is going to be
dont know what exactly the length is going to be
Layman's question:
Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig? I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.
What kind of address length are we looking at with each of the proposals?
Will the proposed new long bitcoin addresses be mandated for everyone going forward, or will the long addresses only be used by people who chose multi-sig? I definitely share the concern over difficulty in copy-paste, QR codes, eye-scanning etc. due to really long addresses.
What kind of address length are we looking at with each of the proposals?
While practical testing is valuable, it should have no bearing on which BIP is accepted. These BIPs are protocol changes, and providing a stable implementation is the duty of the client, not the protocol. That being said, I'm confident that my bitcoind BIP 17 backports are more likely to hold up to testing, provided the signature check is sane (signing the relevant parts of the transaction), which would actually be a bug in the existing protocol if it weren't.
I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
I'm not really up to anything right now. Coiledcoin's dead (probably together with new altchains in general), and it's not really worth starting anything Bitcoin-based at this point in time. I'll see if makomk is up to this. His "coiledcoin" post implied he might be.
Quote
Slow and steady wins the race (and usually results in it being done right the first time).
Normally, I would agree with this. However, BitCoin isn't dealing within a normal environment. If BTC takes hold, it will need to be as far along as possible because there will be great pressures brought to market. Major industries will either try to co-opt it or destroy it. If anyone has been on the receiving end of Multi-Billion dollar industries ire, they will understand 'all' that will be invoked.
Lets not forget, Gavin was already summoned to the CIA.
Transparency helps because of this.
Tycho, Gavin, Luke, etc... as developers are doing what they believe is correct for them, BitCoin, and possibly other reasons. This protocol change, while important, isn't the concern. The concern is the hold up in development. Since BitCoin is a beta and is already being relied on for Millions of dollars in transactions puts great pressure on correctness. It isn't the developers fault that the community put great faith in a beta, it is not their fault. It is ours for assuming it was a full version with all the bugs worked out.
We can't put the Milk back into the Glass. Development should be transparent and debated among the community. The reasons for this, I believe, are simple. Every major communication company has had to 'make deals' with Governments. AT&T, RIM, Google, etc... and this is just for communication. Now being that BitCoin can be used for 'Communication' and 'Money' transferring; I would not be so naive to believe the project wouldn't be put under great pressure, also.
As to stay on topic: BIP16/17, everyone put their heads together come up with all possible 'bad things' and 'good things', and apply Occam's Razor. And Then, PICK ONE. Pick a weekend, get together, get drunk and happy(except Luke
), and pick one. I'll shut up as to this matter as I believe my concerns have been conveyed.
Good Luck and Best Wishes.
Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month?
BIP 17 doesn't change nearly as much as BIP 16, so it's much easier to audit and test. 
Bugs still showing up in BIP 16 sounds like the "deadline" was too rushed. Unless Luke's code is equally well tested and has not been turning out to be buggey we should probably push back the "deadline" to end of next month instead of end of this month?
-MarkM-
-MarkM-
in practice this would be hard if not impossible, the implementation of one bip might mess up something in the other. this will also make future development of bitcoin a lot more complicated
better none than both
better none than both
if you implement both - both will have to be supported forever. you wont be able to choose a "winner" in a later stage
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
implementing both just adds more security risks without any benefits
you would be better off flipping a coin to decide which to use than implementing both
Well if support for one BIP goes down below 50% those coins will become available to redeem for everyone,
at some point all of them will be redeemed rendering a particular BIP obsolete.
Of course the bad thing is that some of those coins will be redeemed by hackers and not by the owners,
but it might happen anyway only if just a single BIP is deployed and support for it goes away.
As I understood BIP16 is currently stronger protected for this kind of situation.
Also, you have to keep in mind that what these BIPs fundamentally do is restrict, not expand, the set of valid transactions. Hence, even if neither Gavin and Luke-jr yield and they create their own separate forks of bitcoin, miners could simply chose to enforce both styles of P2SH transactions to be safe in knowing that whichever style becomes dominant that they'll never end up on a dead fork of the block chain. I'm not advocating this mind you, I think it would be better to just pick one (and no matter which is chosen, make sure it's we'll tested before it's rolled out). But, if it did happen, it wouldn't be the end of bitcoin.
Jump to: