Topic: The Truth behind BIP 16 and 17 (important read) - page 2. (Read 8605 times)
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.
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?
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?
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...
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...
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. 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 posted some stuff about using the Condorcet method in replies to the article.
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. 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.
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.
Good idea, but it solves a problem that never existed (chosing between BIP16 and BIP17).
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.
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.
It seems to me that one of the arguments for these new transactions has been that two devices (device "Alice" and device "Bob", presumably in crypto parlance) cannot work together to make a secret that neither of them alone possess?
But I thought that in fact crypto has already solved the problem of how "Alice" and "Bob" can work together to create keys that enigher of them actually has solo ability to use?
Is that incorrect?
If not, then surely the standard way for Alices and Bobs to do such things can work on the device side without the chain having to know anything about it?
-MarkM-
But I thought that in fact crypto has already solved the problem of how "Alice" and "Bob" can work together to create keys that enigher of them actually has solo ability to use?
Is that incorrect?
If not, then surely the standard way for Alices and Bobs to do such things can work on the device side without the chain having to know anything about it?
-MarkM-
For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
https://bitcointalk.org/index.php?topic=56675
For additional context, as a result of developing it I found and reported a couple of fairly nasty security vulnerabilities in the OP_EVAL implementation that BIP 16 could've inherited - though I believe Gavin may have already found and fixed the second one and just not notified the pools about it. Also, CoiledCoin has been dead for a long time now courtesy of luke-jr having more than 51% of the hash power and using it to block transactions. It's complicated and mostly irrelevant which is why I didn't mention CoiledCoin in the first place. https://bitcointalk.org/index.php?topic=56675
For context: makomk is the creator of CoiledCoin, a bitcoin alternative:
https://bitcointalksearch.org/topic/dead-coiledcoin-yet-another-cryptocurrency-but-with-opeval-56675
And RE: creating bots: I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking). A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).
https://bitcointalksearch.org/topic/dead-coiledcoin-yet-another-cryptocurrency-but-with-opeval-56675
And RE: creating bots: I created a BIP-17-stealing bot because it was really easy (took about 10 minutes of hacking). A BIP-16-stealing bot would be a lot harder (because it would have to 'lie in wait' until the sender was redeeming the coins, and then race to relay/mine a 'stealing' version of the transaction before the rest of the network mined the original).
So apparently, despite the fact that the miners are currently getting to make the decision and are the ones most directly affected by the bugs resulting from the code being deployed in the way it has been, letting them decide is an attack on Bitcoin:
This isn't true. Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.
On the other hand Gavin didn't even try and create a bot to exploit the weakness that exists in BIP16. It also took him quite a while to admit that he'd done it leaving everyone puzzled as to what was going on and who was doing it. (Either would have been quite easy to exploit on testnet and a bit harder to exploit elsewhere from what I recall; testnet isn't an entirely realistic place to test this kind of thing.)I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.
The expectation that many in the future would be 'complex' because all two-factor wallets transactions would be complex. I'd certainly encourage typical users to go this route.
I do see the utility of this, but I find myself wondering if this will really be how the masses will handle most of their transactions; having to always use two devices for every spend can get inconvenient, and people like convenience. Still, yes, were this to become standard (which I personally would dislike) I could see a lot more unspent complex-tx outputs sitting around.
Quote
But it's also not the entirely right question to ask here, because the chain doesn't just carry earnest transactions. If someone wants to DOS attack bitcoin to make it unusable or ruin its decentralization, they'll use the cheapest method available to add the most immortal data to the blockchain. By reducing the amount of potentially immortal data needed in normal financial transactions we reduce that attack, because it is either easily distinguishable from normal transactions (thus subject to higher fees), or isn't as much data.
Hmm. I see your point.
I’m with gmaxwell and BlueMatt. Why turn this technical stuff into a FUD political power struggle debate? It’s not like everyone had an opinion on how encryption should have been done, too. People don’t have to have an opinion on this, it’s up to the developers to achieve consensus.
I’m also with Gavin and Steve. Two-factor Authentication is extremely important for safely using Bitcoin without having the hassle of paper wallets and extra offline computers! Noone except us enthusiasts would go for such lengths, and that could be a reason we are stagnating in terms of users and acceptance.
I don’t understand why this debate exists.
I’m also with Gavin and Steve. Two-factor Authentication is extremely important for safely using Bitcoin without having the hassle of paper wallets and extra offline computers! Noone except us enthusiasts would go for such lengths, and that could be a reason we are stagnating in terms of users and acceptance.
I don’t understand why this debate exists.
FYI, earlier this morning Gavin solved the 1000-multisig-input limitation on BIP 17. I'm in the process of drafting a new BIP to cover these scripts (this isn't directly P2SH related) now.
P.S. I don't claim that Gavin is supportive of BIP 17 in light of this solution. I don't know if he is or not.
P.S. I don't claim that Gavin is supportive of BIP 17 in light of this solution. I don't know if he is or not.
I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.
The expectation that many in the future would be 'complex' because all two-factor wallets transactions would be complex. I'd certainly encourage typical users to go this route.
But it's also not the entirely right question to ask here, because the chain doesn't just carry earnest transactions. If someone wants to DOS attack bitcoin to make it unusable or ruin its decentralization, they'll use the cheapest method available to add the most immortal data to the blockchain. By reducing the amount of potentially immortal data needed in normal financial transactions we reduce that attack, because it is either easily distinguishable from normal transactions (thus subject to higher fees), or isn't as much data.
To risk permanent harm to the system...
There is no risk of permanent harm.
Hmm. I'm going by what I've read on the other thread. I seem to recall one of the big points of contention was that, essentially, "we can't screw this up, because if we do, we won't ever be able to fix it."
One example:
And, at the same time, there's nothing stopping anyone from implementing both. It's conceivable someone could create a client that did the validation for both BIP-16 and BIP-17. Miners could also validate both style transactions. Since they are both designed to be backward compatible, they will all be recognized as legitimate transactions by the whole network if they get into a block (even if not all clients relay them). The downside of course is that if you create either a BIP-16 or BIP-17 style transaction and the majority of mining power isn't doing the full validation, you run the risk of losing your coins to theft.
Perhaps its more accurate to say implementing either risks causing serious problems.
And the blockchain bloat? That almost seems like a distraction. Complex transactions are going to take up extra space in the blockchain; arguing over where and when the bloat occurs seems pretty academic too.
You forget that completed transactions can be pruned. They can and will be deleted by many miners after the bitcoins are spent further. Unspent bitcoins can not. They are kept by all miners forever. These BIPs would reduce the size of unspent transactions, no matter how complex, to the lowest safe size. It is not merely academic. It is significant.
Unspent bitcoins are only kept by miners until they are spent.
Sure, there will be some "lost" coins... coins sent using complex transactions where the recipient loses the private key, dies before spending the coins, etc. But I think that's a negligible situation that shouldn't dictate the protocol.
I think the real question is, how long on average will coins sent via complex transactions remain unspent? If the intention is for most transactions in the future to become complex (which I'm seeing hints of, and if so, I'd love to be pointed to where this is actually discussed openly,) then I see your point, but I don't see that that as a given.
Even if the average time delay of spending coins from complex transactions is months (which sounds highly unlikely,) it still just delays the pruning. A "rolling amount" of temporary bloat from some unspent complex-tx coins doesn't seem like it would be enough to worry about.
you can prune in a way that you can still validate. you will only nee to keep 1 transaction per block and the merkle tree hashes.
I guess it will only matter for light clients then.
I guess it will only matter for light clients then.
then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate.
This is always the case for pruning, or at least pruning naively implemented. The reference client will support both modes of operation some day. I have a half dozen copies of the blockchain at home, thats silly and non-scalable.
The alternative to pruning isn't not pruning— FWIW— if the reference client doesn't gain the ability to prune more and more people will move to nodes like multibit which don't validate _at all_, and bitcoin will lose its decentralization. Bootstrapping is important, but its irrelevant if you can't afford the runtime costs.
Quote
the way i see it, if you decided to keep the blockchain - you should never prune so it cant be validated. if you don't want to keep it, you can delete all of the blocks right after validation and just keep a signed (by yourself) copy of unspent transactions.
You need to keep enough to allow you to reorganize, but yes. P2SH minimizes the size of that set of that unspent data (by a factor of 2-4 or so, depending on what kind of assumptions you make on the frequency of complicated transactions). It does this without any particular 'costs', except the cost of deploying something new now. It's just one of the several advantages of using P2SH style transactions.
it becomes relevant if you add it to the default client.
then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate.
then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate.
Pruning will not be so naïvely implemented.
Quote
(the connecting tree isn't relevant, because you've already validated the transactions for yourself, you don't need to continually prove to yourself that you weren't lying to yourself)
it becomes relevant if you add it to the default client. then everyone will remove the inputs, and new clients downloading the blockchain will have trouble finding a record they can validate. (and if a new client cant validate, maybe an attacker will be able to generate a longer chain by manipulating some of the hashes)
the way i see it, if you decided to keep the blockchain - you should never prune so it cant be validated. if you don't want to keep it, you can delete all of the blocks right after validation and just keep a signed (by yourself) copy of unspent transactions.
Jump to: