Technomage
Legendary
Offline
Activity: 2184
Merit: 1056
Affordable Physical Bitcoins - Denarium.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 01:20:53 AM |
|
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.
|
Denarium closing sale discounts now up to 43%! Check out our products from here!
|
|
|
Steve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 01:26:11 AM |
|
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. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I posted some stuff about using the Condorcet method in replies to the article.
|
|
|
|
Andrew Vorobyov
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 08:26:08 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 10:32:02 AM |
|
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
Donator
Legendary
Offline
Activity: 1736
Merit: 1010
Let's talk governance, lipstick, and pigs.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 11:45:39 AM |
|
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.
|
Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
|
|
|
EhVedadoOAnonimato
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 12:41:36 PM |
|
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
Legendary
Offline
Activity: 1222
Merit: 1016
Live and Let Live
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 12:48:28 PM |
|
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.
|
One off NP-Hard.
|
|
|
EhVedadoOAnonimato
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 02:25:10 PM |
|
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
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 03:25:21 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 31, 2012, 03:33:15 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:05:27 PM |
|
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.
|
BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:32:11 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 10:38:02 PM |
|
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.
|
BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
|
|
|
2_Thumbs_Up
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 11:07:14 PM Last edit: February 02, 2012, 11:24:24 PM by 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 11:26:10 PM |
|
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.
|
BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
|
|
|
2_Thumbs_Up
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 11:44:25 PM |
|
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]
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 02, 2012, 11:44:44 PM |
|
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.
|
Welcome to my bitcoin mining pool: https://deepbit.net - Both payment schemes (including PPS), instant payout, no invalid blocks ! ICBIT Trading platform : USD/BTC futures trading, Bitcoin difficulty futures ( NEW!). Third year in bitcoin business.
|
|
|
Atheros
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 03, 2012, 12:15:46 AM |
|
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.
|
BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
|
|
|
westkybitcoins
Legendary
Offline
Activity: 980
Merit: 1004
Firstbits: Compromised. Thanks, Android!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 03, 2012, 06:52:13 PM |
|
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.
|
Bitcoin is the ultimate freedom test. It tells you who is giving lip service and who genuinely believes in it.
... ... In the future, books that summarize the history of money will have a line that says, “and then came bitcoin.” It is the economic singularity. And we are living in it now. - Ryan Dickherber... ... ATTENTION BFL MINING NEWBS: Just got your Jalapenos in? Wondering how to get the most value for the least hassle? Give BitMinter a try! It's a smaller pool with a fair & low-fee payment method, lots of statistical feedback, and it's easier than EasyMiner! (Yes, we want your hashing power, but seriously, it IS the easiest pool to use! Sign up in seconds to try it!)... ... The idea that deflation causes hoarding (to any problematic degree) is a lie used to justify theft of value from your savings.
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 03, 2012, 07:02:33 PM |
|
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.
|
|
|
|
|