Bitcoin Forum
December 10, 2016, 04:58:21 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 [4] 5 »  All
  Print  
Author Topic: The Truth behind BIP 16 and 17 (important read)  (Read 7695 times)
markm
Legendary
*
Offline Offline

Activity: 1792



View Profile WWW
January 31, 2012, 12:33:24 AM
 #61

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-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
1481389101
Hero Member
*
Offline Offline

Posts: 1481389101

View Profile Personal Message (Offline)

Ignore
1481389101
Reply with quote  #2

1481389101
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481389101
Hero Member
*
Offline Offline

Posts: 1481389101

View Profile Personal Message (Offline)

Ignore
1481389101
Reply with quote  #2

1481389101
Report to moderator
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
January 31, 2012, 12:52:11 AM
 #62

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.
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
January 31, 2012, 01:02:25 AM
 #63

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).

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.
Technomage
Legendary
*
Offline Offline

Activity: 1624


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
January 31, 2012, 01:20:53 AM
 #64

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 - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 31, 2012, 01:26:11 AM
 #65

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

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

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
January 31, 2012, 08:26:08 AM
 #66

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 31, 2012, 10:32:02 AM
 #67

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 Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
January 31, 2012, 11:45:39 AM
 #68

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 31, 2012, 12:41:36 PM
 #69

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 Offline

Activity: 1218


Live and Let Live


View Profile
January 31, 2012, 12:48:28 PM
 #70

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 31, 2012, 02:25:10 PM
 #71

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 Offline

Activity: 2100



View Profile
January 31, 2012, 03:25:21 PM
 #72

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
January 31, 2012, 03:33:15 PM
 #73

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
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
February 02, 2012, 10:05:27 PM
 #74

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 Offline

Activity: 2100



View Profile
February 02, 2012, 10:32:11 PM
 #75

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
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
February 02, 2012, 10:38:02 PM
 #76

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
Sr. Member
****
Offline Offline

Activity: 323


View Profile
February 02, 2012, 11:07:14 PM
 #77

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
Sr. Member
****
Offline Offline

Activity: 249



View Profile WWW
February 02, 2012, 11:26:10 PM
 #78

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
Sr. Member
****
Offline Offline

Activity: 323


View Profile
February 02, 2012, 11:44:25 PM
 #79

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]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
February 02, 2012, 11:44:44 PM
 #80

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.
Pages: « 1 2 3 [4] 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!