Bitcoin Forum
December 05, 2016, 08:48:28 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5] 6 »  All
  Print  
Author Topic: BIP 17  (Read 8106 times)
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 27, 2012, 08:59:58 AM
 #81

With reasonable justification but with little regard for propriety or the long-term consequences, Luke-Jr objects to Gavin's scheme's violation of the script and uses his considerable technical and social capital to engineer the scheme's failure. This brings us up-to-date.
You forgot to mention "engineering its failure" includes "engineering a better, sane proposal"... BIP 17

1480970908
Hero Member
*
Offline Offline

Posts: 1480970908

View Profile Personal Message (Offline)

Ignore
1480970908
Reply with quote  #2

1480970908
Report to moderator
1480970908
Hero Member
*
Offline Offline

Posts: 1480970908

View Profile Personal Message (Offline)

Ignore
1480970908
Reply with quote  #2

1480970908
Report to moderator
1480970908
Hero Member
*
Offline Offline

Posts: 1480970908

View Profile Personal Message (Offline)

Ignore
1480970908
Reply with quote  #2

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

Posts: 1480970908

View Profile Personal Message (Offline)

Ignore
1480970908
Reply with quote  #2

1480970908
Report to moderator
Inaba
Legendary
*
Offline Offline

Activity: 1260



View Profile WWW
January 27, 2012, 02:27:11 PM
 #82

My assessment is that the current state of disagreement is a rather freakish conspiracy of circumstances and would have been impossible to predict and/or avoid. Please outline how it was botched. Here's a little history as I see it:

I left out the outline you already gave, as I have no objective assessment as to it's accuracy (or inaccuracy) - the part I would add, that I would consider the important botched part:

BIP 16 proposed on 3 Jan 12, deadline for changes to bitcoind for miners (realistically, the big pools) to be 1 Feb 12.  Giving less than 4 weeks to implement changes, test, deploy and mine.  No direct contact of the major players making up 55%+ of the mined blocks, with the possible exception of Slush(?) and/or Tycho (?) in "secret." 

The time frame is too short, and the lack of communication as to the ramifications/reasons to the people who mine the majority of the blocks is the problem.  If either of those two situations had been handled, the other one probably would have sorted itself out, but since neither issues was handled properly, the entire operation was botched.

If you're searching these lines for a point, you've probably missed it.  There was never anything there in the first place.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 27, 2012, 10:15:34 PM
 #83

No direct contact of the major players making up 55%+ of the mined blocks, with the possible exception of Slush(?) and/or Tycho (?) in "secret." 

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.

I probably should have posted all of my followup emails to them in the Mining Pools forum, also; as I said, I'm terrible at that kind of "keep track of who you've told what and make sure you've got 'buy-in' from X Y and Z" thing.

I think my only really major blunder was being too stubborn about inserting some wording into BIP 16 that Luke wanted inserted; I let my emotions cloud my judgement.

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

Activity: 2086



View Profile
January 27, 2012, 10:57:30 PM
 #84

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.
This was about OP_EVAL (BIP 12). All communications about BIP 16, if any, were kept secret until I brought it into public light... I don't recall getting any myself, despite running one of the top 10 pools.

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 27, 2012, 11:04:49 PM
 #85

gavin, do you have any commercial interest in implementing P2SH?
RaggedMonk
Sr. Member
****
Offline Offline

Activity: 308



View Profile
January 27, 2012, 11:54:03 PM
 #86

gavin, do you have any commercial interest in implementing P2SH?

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 27, 2012, 11:57:45 PM
 #87

somebody suggested that he had contacted a commercial company for making HW keys for bitcoin wallets - similar to what mtgox has.
to use such a device with bitcoin P2SH might be very helpful - 1 key on the PC , 1 key on the device
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
January 28, 2012, 12:00:51 AM
 #88

somebody suggested that he had contacted a commercial company for making HW keys for bitcoin wallets - similar to what mtgox has.
to use such a device with bitcoin P2SH might be very helpful - 1 key on the PC , 1 key on the device
Even if Gavin does have a monetary incentive to implement P2SH, that doesn't mean he will only support BIP 16. It just means that he will want the code written quickly.  If he wants a company behind it, that is just more incentive to make sure that P2SH works properly.

The WTF image was posted because your question has little relevance, not because of some misunderstanding.

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 28, 2012, 12:08:22 AM
 #89

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.
I just want to make sure the reasons to opposing BIP17 are not commercial (aka a set release date for a commercial product).

Any bip16/17 thread gets off topic quite fast :\
if anyone wanted to know the details - they are posted in the wiki
I cant see any chance of an objective and/or productive discussion of this topic on the forums...
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 28, 2012, 01:42:27 AM
 #90

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.
BIP 17 is already implemented, and easily tested. The delays at this point are because people won't let BIP 16 go.

cunicula
Hero Member
*****
Offline Offline

Activity: 756


Stack-overflow Guru


View Profile WWW
January 28, 2012, 02:07:27 AM
 #91

one of the reasons bip17 is not well accepted is because it will take more time to implement and test - delaying the introduction of P2SH.
BIP 17 is already implemented, and easily tested. The delays at this point are because people won't let BIP 16 go.

It does seem like giving in to a guy with such one-sided interpretations of events is like giving into a terrorist. Since he is quite willing to approach controversies from an extremist and catastrophic point of view, there is no way to establish bargaining power with him unless you hold your ground.

quid pro quo won't work

▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
        AltCoinInternalExperts                Get Your Altcoin Promoted On Social Media       
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
January 28, 2012, 11:53:38 AM
 #92

I don't have an opinion this, but I have some related questions.

1) Where is MAX_SIGOPS validated? In isStandard(), right?

I think it should be there. I'm ok with having that function for sanity, but I think the door should be open to stop using it in the future, to leave it out of the protocol (although maybe each implementation runs its own version of the function, depending on its performance variables). Not sure how each proposal affects that part I just read something about it somewhere in these discussions.

2) Probably there's a good reason but...Why a scripting language is needed in the first place?
Why don't just a set of validations that must be all true, operators with parameters and references to other elements in the script?

Standard Transaction to Bitcoin address

Code:
scriptPubKey: OP_HASH_EQUAL(<pubKeyHash>), OP_CHECKSIG(scriptSig[0])
scriptSig: <pubKey>, <sig>

Multi-signature

Code:
scriptPubKey: OP_HASH_EQUAL(<pubKeyHash1>) OR OP_HASH_EQUAL(<pubKeyHash2>) OR OP_HASH_EQUAL(<pubKeyHash3>),
       scriptPubKey[0], scriptSig[0] != scriptSig[1], OP_CHECKSIG(scriptSig[0]),  OP_CHECKSIG(scriptSig[1])
scriptSig: <pubKey1>, <pubKey3>, <sig1>, <sig3>

another valid scriptSig
Code:
scriptSig: <pubKey2>, <pubKey1>, <sig2>, <sig1>

Wouldn't something like this be more secure and achieve the same things?
Of course, this would not be feasible for compatibility issues, I just want to know the reasons behind the stack language.

EDIT
Sorry, I just found this thread:
https://bitcointalk.org/index.php?topic=61248.0

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

Activity: 28



View Profile
January 28, 2012, 12:29:36 PM
 #93

why not just add another field into a transaction at the output and implement the "ideal" 3 parts solution gavin sugested?
Is there a way to make old clients ignore an unknown field?
 
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
January 28, 2012, 03:05:01 PM
 #94

EDIT
Sorry, I just found this thread:
https://bitcointalk.org/index.php?topic=61248.0

We could add a hashScriptPubKey field and let scriptPubKey be presented at redemption. My question remains.
Why do we need a stack based language?

3) Also, the scriptPubKey it's going to end up in the chain anyway. Why the moment matters so much?

why not just add another field into a transaction at the output and implement the "ideal" 3 parts solution gavin sugested?

As Gavin explains, it's not possible for backwards compatibility.
I'm not making a proposal, just trying to understand bitcoin better.
I'm not directly involved in the bitcoin development and I don't think my voice counts much in this purely technical controversy.
I mean, if both proposals end up being equally secure, for the end user, both do the same thing.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
[Tycho]
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
January 28, 2012, 03:12:06 PM
 #95

3) Also, the scriptPubKey it's going to end up in the chain anyway. Why the moment matters so much?
If you are asking about the public key, then usually it appears in the blockchain only when it doesn't matters anymore (for one-time addresses).
So if someone can "break" the signature using only pubkey, he won't be dangerous because if pubkey is used for redeeming then that address is empty already.

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

Activity: 1246


View Profile WWW
January 29, 2012, 09:36:50 AM
 #96

I found better answers for the third question:

Quote from: Amir Taaki
-You would have to pay to long addresses.

Quote from: Gregory Maxwell
(1) They are highly vulnerable to invisible substitution.  E.g. I can
 trivially take a P2S address, change one or two characters and get a
 script which is redeemable by anyone.  With P2SH you have to do
 computation which is exponential in the number of unchanged digits to
 get a look alike address.

 (2) The sender is fully responsible for fees related to the enlarged
 transactions. Even if _you're_ willing to take the txn-processing time
 and fee burden of a 30 person joint trust address,  random e-commerce
 sites will not be and will randomly reject your addresses.

 (3) They create another input vector for non-trivial data which must
 be inspected and validated, potentially presenting an attack surface.

 (4) They leave the complicated (long) release rules in the transaction
 outputs.  When a transaction is mined we can't be sure if it will ever
 be redeemed. The outputs are unprunable.   In a future world where
 many nodes prune output space is far more important than input space
 and it would make sense to require more fees for it because we're
 never sure how long it would need to be stored (making it an
 attractive target for someone who wants to make Bitcoin unusable by
 spamming it with worthless data).  P2SH reduces output sizes to the
 absolute minimum without inflating the total data size.

The other questions are still open.

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

Activity: 882


Spurn wild goose chases. Seek that which endures.


View Profile WWW
January 30, 2012, 06:44:05 PM
 #97

As someone who only understands the Bitcoin algorithm on a high level, I want to get a better understanding of what multi-sig is for.

My impression is that the feature involves the creation of an address with two private keys, each generated by a party who doesn't have to know the other one. In other words, an address where both key-generators would have to be compromised for the coins at that address to be compromised.

My impression was also that ECDSA already has that feature, based on some kind of magic where you multiply Party 1's private key and Party 2's public key (and vice versa). I remember Mike Caldwell (the Casascius guy) talking about this method with whoever runs Printbills as a possible means of adding confidence in the security of the Bitcoins backing a piece of physical currency.

Was one of these impressions incorrect? Does that magic of multiplying ECDSA keys not work really, or is there something else that these BIPs do that justifies a change in the protocol?

If there is something that will make Bitcoin succeed, it is growth of utility - greater quantity and variety of goods and services offered for BTC. If there is something that will make Bitcoin fail, it is the culture of naive fools and conmen, the former convinced that BTC is a magic box that will turn them into millionaires, and the latter arriving by the busload to devour them.
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 30, 2012, 06:58:19 PM
 #98

We could add a hashScriptPubKey field and let scriptPubKey be presented at redemption. My question remains.
Why do we need a stack based language?
As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

(gasteve on IRC) Does your website accept cash? https://bitpay.com
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
January 30, 2012, 08:33:14 PM
 #99

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

That bytecode is also a formal language. I'm not talking about performance improvements, so it doesn't matter much if the interpreter interprets bytecodes or strings containing operators names such as "OP_CHECKSIG". Both would be equivalent in what they can do (but the second notably worse for storage).
My point is, why have such a potent language?
Why not just a list of bytecodes that express conditions to be validated?
Separating from the beginning the operator scripts from the data?
You have a list of data and a stack of operators that can refer to that data as variables or use constants for the parameters of the operators.
You wouldn't have flow control or stack words, for example.
I guess the reason is to allow use cases that aren't thought of yet, but new words can be added later, as is the case for p2sh.
Well, kind of answered myself now: a more potent language needs to be extended less times and extending the language is really an issue with a blockchain to agree.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
Steve
Hero Member
*****
Offline Offline

Activity: 868



View Profile WWW
January 30, 2012, 10:18:19 PM
 #100

As opposed to what?  A register based language?  Note that what bitcoin implements is just a bytecode interpreter, not a language.  You could chose to implement a more user friendly language that compiles to bitcoin bytecode if you chose to, but the benefits would be marginal at best given that the scripts are very small.  It's not like you have to wade through pages and pages of the stuff when talking about your typical script.  People have already invented a defacto language when talking about bitcoin scripts (using "OP_CHECKSIG" instead of its bytecode…or {} to denote stuff pushed on the stack).

That bytecode is also a formal language. I'm not talking about performance improvements, so it doesn't matter much if the interpreter interprets bytecodes or strings containing operators names such as "OP_CHECKSIG". Both would be equivalent in what they can do (but the second notably worse for storage).
My point is, why have such a potent language?
Why not just a list of bytecodes that express conditions to be validated?
Separating from the beginning the operator scripts from the data?
You have a list of data and a stack of operators that can refer to that data as variables or use constants for the parameters of the operators.
You wouldn't have flow control or stack words, for example.
I guess the reason is to allow use cases that aren't thought of yet, but new words can be added later, as is the case for p2sh.
Well, kind of answered myself now: a more potent language needs to be extended less times and extending the language is really an issue with a blockchain to agree.
Right…and with p2sh, the impetus is really on the receiver of coins to ensure whatever script they come up with is free from any defects that might allow unauthorized people to spend their coins.  Which is how it should be.  Someone could create a script that allowed anyone to spend the coins, but that's an issue for the script author, not bitcoin itself.  If anything, scripts should be allowed to access even more data related to a transaction or the block chain.  For instance, your script might check whether the input transaction has at least N confirmations.  Or it might want to check that a certain percentage of the input amount goes to certain output addresses (you can imagine this might be useful for a payment processor like bit-pay that doesn't want to ever have control over the full amount of a transaction, but instead just redirect a percentage of the value of the transaction).

(gasteve on IRC) Does your website accept cash? https://bitpay.com
Pages: « 1 2 3 4 [5] 6 »  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!