Bitcoin Forum
December 05, 2016, 08:48:29 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 »  All
  Print  
Author Topic: Deadlines and moving forward (BIP 16/17 support)  (Read 7211 times)
Vitalik Buterin
Sr. Member
****
Offline Offline

Activity: 331


View Profile
January 31, 2012, 01:01:46 PM
 #41

Is there any problem with just keeping both BIPs open until one is decided on?

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

Argumentum ad lunam: the fallacy that because Bitcoin's price is rising really fast the currency must be a speculative bubble and/or Ponzi scheme.
1480970909
Hero Member
*
Offline Offline

Posts: 1480970909

View Profile Personal Message (Offline)

Ignore
1480970909
Reply with quote  #2

1480970909
Report to moderator
1480970909
Hero Member
*
Offline Offline

Posts: 1480970909

View Profile Personal Message (Offline)

Ignore
1480970909
Reply with quote  #2

1480970909
Report to moderator
1480970909
Hero Member
*
Offline Offline

Posts: 1480970909

View Profile Personal Message (Offline)

Ignore
1480970909
Reply with quote  #2

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

Posts: 1480970909

View Profile Personal Message (Offline)

Ignore
1480970909
Reply with quote  #2

1480970909
Report to moderator
interlagos
Hero Member
*****
Offline Offline

Activity: 497


View Profile
January 31, 2012, 01:43:08 PM
 #42

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

I can agree to this if there will be a mechanism to preserve "wealth" of current network and transfer it into the new one..

Really, can you, developers, come up with a script that does this? Like CTRL-C CTRL-V

I think there have been a precedent like this in one of the alt-chains starting with S Smiley
They suspended 1.0 chain and somehow transferred all wealth into 2.0 chain which had new rules and its own genesis block.
So it should be possible at least theoretically.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2016



View Profile
January 31, 2012, 02:27:26 PM
 #43

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position. Smiley
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 31, 2012, 07:21:35 PM
 #44

Yes. Some of us are perfectly fine with complex transactions having addresses a hundred characters long and that is just as legitimate an option as BIP-16, 17, or anything else that could possibly replace them.

I challenge you to demonstrate how well informed you are on this sub-subject by linking to posts giving at least three total distinct arguments against that position. Smiley

Some of them may be less important than you think. For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
flower1024
Hero Member
*****
Offline Offline

Activity: 854


luck is just a share away


View Profile
January 31, 2012, 08:19:43 PM
 #45

Miners (as a group) should not be given any say over issues like this. They do not necessarily know what the best option is. The issue should be decided by people very familiar with the protocol and the proposals.

I suggest that we compile a list of everyone who knows a lot about the Bitcoin protocol, invite them to a two-week discussion via email, and have those who participate in the discussion vote on the issue at the end of the two weeks. If one proposal gets enough votes (two-thirds, say), then Bitcoin clients will be programmed to apply the new restrictions ~3 months in the future. Miners will have to upgrade by then or their blocks will not be recognized by most clients. If there aren't enough votes for any proposal to pass, the issue will be shelved for a while.

+1
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2016



View Profile
January 31, 2012, 08:31:54 PM
 #46

Some of them may be less important than you think.

I don't think any particular issue is the end of the world— but the representation that we can just use big addresses and it's no big deal is ignoring that there are other issues. I know you know about some of them. But I don't believe most people saying "oh, big addresses are no big deal" do.

Quote
For example, I seem to recall you were worried that someone malicious could easily create their own pay-to-script address that only differed from the genuine address by a few characters but could be redeemed by them instead. There's an obvious solution to that if you don't care about address length: append the 160-bit hash of the script to the start of the address. That way, the more characters at the start someone compares, the harder it is to trick them.

Interesting thought, I hadn't considered that possibility. But "We can handle longer ones" isn't the same as "don't care" by doing that the minimum length for a 2of2 simple secured wallet, pretty much the simplest case, probably won't fit in a tweet anymore (for example), they won't fit in the small QR codes anymore, etc.

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc. Smiley  Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.


eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 966


felonious vagrancy, personified


View Profile WWW
January 31, 2012, 08:43:04 PM
 #47

can we see theymos idea + non-backwards compatible new standard?

a blockchain fork will have to happen in the future.

see this as a good testbed, practice run or training level.

if we cannot get it right then bitcoin is doomed.

They suspended 1.0 chain and somehow transferred all wealth into 2.0 chain which had new rules and its own genesis block.

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
January 31, 2012, 11:15:48 PM
 #48

Do you have a magic solution to recipients losing the freedom to have complicated rules because the sender doesn't want to handle the TXN fees or risk of slow processing?  The concentration of more data in unprunable unspent outputs? etc. Smiley  Thats it— it's just not simply "big addresses", there are other issues even if they aren't super major.
Nope, no magic solutions to either of those sadly - there's a reason that I supported the idea of P2SH back in the OP_EVAL era before the whole thing turned into a circus, and in fact Coiledcoin started off as my personal testbed for playing with it with all the mainnet checks still in operation. Something that works is better than something that might work eventually though.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Killdozer
Full Member
***
Offline Offline

Activity: 204



View Profile
February 01, 2012, 12:46:39 AM
 #49

Quote
No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

Seems like even a possible solution to the everbloating blockchain problem.

jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
February 01, 2012, 09:00:47 AM
 #50

No need to suspend chains.  Just create a new transaction type that renders coins "unspendable" and includes a public key.  Have the new chain's rules include a clause allowing the holder of the corresponding private key to create an equal amount of coins on the new chain.

With merged mining the fork won't even sacrifice hashpower.

This avoids the need for any sort of agreement/voting/cabal.  Each user decides which chain they want their coins to be on.  It isn't even "one coin, one vote" -- it's simply letting people move their coins to whichever system they feel best meets their needs.

Maybe that should be here for later forks, but as far as I know neither BIP 16 nor 17 need a fork like that. Old clients will remain compatible.

Quote from: Gregory Maxwell
Quote
If the change is going to be a big one anyway and will require a client upgrade why not...

It does not, in fact— Yes, it requires a client update to make use of the new functionality, but old nodes will happily continue to validate things.  It's hard to express how critical this is distinctly. Bitcoin is, predominantly, a zero-trust system. Nodes don't trust that things were done right, the validate them for themselves.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 01, 2012, 02:31:46 PM
 #51

OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

It is time to call it settled and move on to bigger and better things, like what protocol to use when a client needs to gather signatures (REST? JSON? http? https? something else?).

How often do you get the chance to work on a potentially world-changing project?
Technomage
Legendary
*
Offline Offline

Activity: 1610


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 01, 2012, 02:51:00 PM
 #52

OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).
+1

That vote seems to indicate a strong preference for BIP16. Now it's up to the miners to do what is right, as far as I know slush is still supporting BIP16 right? Don't forget to add his pool to your signature. Smiley

Denarium - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
blueadept
Full Member
***
Offline Offline

Activity: 225


View Profile
February 01, 2012, 07:29:36 PM
 #53

...as far as I know slush is still supporting BIP16 right? Don't forget to add his pool to your signature. Smiley

Bitcoin.cz is slush's pool.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
eleuthria
Legendary
*
Offline Offline

Activity: 1750


BTC Guild Owner


View Profile WWW
February 02, 2012, 09:45:51 PM
 #54

BTC Guild blocks will be containing BIP 16 support, hopefully between February 10 and 12.

R.I.P. BTC Guild, 2011 - 2015.
BTC Guild Forum Thread
Technomage
Legendary
*
Offline Offline

Activity: 1610


Affordable Physical Bitcoins - Denarium.com


View Profile WWW
February 02, 2012, 10:49:10 PM
 #55

BTC Guild blocks will be containing BIP 16 support, hopefully between February 10 and 12.
+1

This is great news.

Denarium - Leading Physical Bitcoin Manufacturer - Special Xmas deals now live!
Balthazar
Legendary
*
Offline Offline

Activity: 1988


Post rank racist


View Profile
February 03, 2012, 08:43:29 PM
 #56

We successfully migrated to git snapshot of bitcoin-0.5.1 with P2SH/CHV patches today.

Waiting for block... Smiley

novaco.in | VMWare VMHGFS driver for 3.19.x kernels | Ukrainian translation for Novacoin [Done]
฿: 1GV8D5SRkA3cPccpYhVc2wMkjwz3UREEpy: 4RgnHWtnJWEyMhqhDdazW3Hdr7cx5ybF6i
P4man
Hero Member
*****
Offline Offline

Activity: 504



View Profile
February 03, 2012, 09:23:39 PM
 #57

Ill throw in my 2 cents, even if Im too late Smiley

In a democracy, on most complex financial/economic/political/etc issues, ordinary voters "are not qualified" either. But they do vote, as they should; they vote representatives who are supposed to know these issues better. I think the same goes here, I may not understand all the technical ins and outs of BIP16, but I know what its about and to put it very simple, to me it boils down to, do I trust Gavins judgment above Lukes?
I think thats actually quite a reasonable approach to follow. You can decide to put faith in a pool op, or actively decide which pool you will join that supports you POV. Its almost like political parties Smiley.

To continue my parallel with democracy; non voters dont get counted. I dont see why we should count them here (unless maybe there was a way to vote "undecided"). This process is new, so we should give it some time otherwise  it may cause a bit of a panic initially, but if you make votes binding and ignore the non voters, Im sure quickly miners and pools will get more involved and more interested in whats going on to make sure they cast the right votes. If they dont, their votes are simply ignored, i see no reason to allow non voters to halt the development of bitcoin.

ThePok
Full Member
***
Offline Offline

Activity: 137


View Profile
February 03, 2012, 09:44:55 PM
 #58

Thats a great Idea!

People that dont Vote dont care, are not infomrmed, so they dont count. People that did make a desicition sure did think a while about it. But we need more than the currrent 2 Options:

Vote Pro BIP16
Vote Pro BIP17
Vote None Yet

All other Blocks without vote dont count.

But theres a Problem too, if to manny miners dont care for the Wnner of the Vote, a Win of the Votingprocess didnt help Sad

But Votingprocess is much faster Smiley

Rassah
Legendary
*
Offline Offline

Activity: 1624


Director of Bitcoin100


View Profile
February 03, 2012, 09:59:39 PM
 #59

In a democracy, on most complex financial/economic/political/etc issues, ordinary voters "are not qualified" either. But they do vote, as they should; they vote representatives who are supposed to know these issues better.

LOL! As long as those representatives are not "East-coast Educated Elites™" and are good at "sitting down to have a beer with"  Grin
Because economics and finances that involve complicated mumbo jumbo are just liberal lies in disguise, and not good, down-to-earth, Reagan-style, Amuhrican economics  Roll Eyes

runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
February 04, 2012, 07:14:52 PM
 #60

To continue my parallel with democracy; non voters dont get counted. I dont see why we should count them here (unless maybe there was a way to vote "undecided").
As far as I understand, we need to count the vote of the non-voting miners, because we need the support of the miners for PS2H to work. That's why we're waiting for over 50% to actively proclaim that they support PS2H transactions, and that they will be including them in blocks when these transactions start to appear.
Pages: « 1 2 [3] 4 »  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!