BIP 17 | Bitcointalksearch.org

interlagos

hero member

Activity: 496

Merit: 500

Quote from: Costia on January 30, 2012, 07:04:47 PM

for the address you only need the public keys and script - you can store those on the PC

for the redeeming transaction you need the signature, public key and script
you need the private key to make a signature
so:
PC creates using key1
phone creates using key2
phone sends (not the key) to PC
the sig is valid only for this transaction, and it must belong to the public key in the address, this will end up being in the transaction anyway, so there are no "secrets" transmitted over the internet
PC puts everything together and creates a redeeming transaction

Ok that explains it, thanks!

Costia

newbie

Activity: 28

Merit: 0

for the address you only need the public keys and script - you can store those on the PC

for the redeeming transaction you need the signature, public key and script
you need the private key to make a signature
so:
PC creates using key1
phone creates using key2
phone sends (not the key) to PC
the sig is valid only for this transaction, and it must belong to the public key in the address, this will end up being in the transaction anyway, so there are no "secrets" transmitted over the internet
PC puts everything together and creates a redeeming transaction

interlagos

hero member

Activity: 496

Merit: 500

I have a small question.
If two private keys always need to be kept separate,
how one would generate a single address which would combine both of them without having both of them on a single device at one point?

Steve

hero member

Activity: 868

Merit: 1008

Quote from: jtimon on January 30, 2012, 03:33:14 PM

Quote from: Steve on January 30, 2012, 01:58:19 PM

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

jtimon

legendary

Activity: 1372

Merit: 1002

Quote from: Steve on January 30, 2012, 01:58:19 PM

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.

Steve

hero member

Activity: 868

Merit: 1008

Quote from: jtimon on January 28, 2012, 10:05:01 AM

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

Qoheleth

legendary

Activity: 960

Merit: 1028

Spurn wild goose chases. Seek that which endures.

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?

jtimon

legendary

Activity: 1372

Merit: 1002

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.

[Tycho]

hero member

Activity: 742

Merit: 500

Quote from: jtimon on January 28, 2012, 10:05:01 AM

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.

jtimon

legendary

Activity: 1372

Merit: 1002

Quote from: jtimon on January 28, 2012, 06:53:38 AM

EDIT
Sorry, I just found this thread:
https://bitcointalksearch.org/topic/bip-16-big-picture-61248

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?

Quote from: Costia on January 28, 2012, 07:29:36 AM

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.

Costia

newbie

Activity: 28

Merit: 0

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

Activity: 1372

Merit: 1002

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(), OP_CHECKSIG(scriptSig[0])
scriptSig: ,

Multi-signature

Code:

scriptPubKey: OP_HASH_EQUAL() OR OP_HASH_EQUAL() OR OP_HASH_EQUAL(), 
       scriptPubKey[0], scriptSig[0] != scriptSig[1], OP_CHECKSIG(scriptSig[0]),  OP_CHECKSIG(scriptSig[1])
scriptSig: , , ,

another valid scriptSig

Code:

scriptSig: , , ,

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://bitcointalksearch.org/topic/bip-16-big-picture-61248

cunicula

legendary

Activity: 1050

Merit: 1003

Quote from: Luke-Jr on January 27, 2012, 08:42:27 PM

Quote from: Costia on January 27, 2012, 07:08:22 PM

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Costia on January 27, 2012, 07:08:22 PM

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.

Costia

newbie

Activity: 28

Merit: 0

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

Red Emerald

hero member

Activity: 742

Merit: 500

Quote from: Costia on January 27, 2012, 06:57:45 PM

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

Activity: 28

Merit: 0

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

RaggedMonk

sr. member

Activity: 308

Merit: 250

Quote from: Costia on January 27, 2012, 06:04:49 PM

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

Costia

newbie

Activity: 28

Merit: 0

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

Luke-Jr

legendary

Activity: 2576

Merit: 1186

Quote from: Gavin Andresen on January 27, 2012, 05:15:34 PM

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.

Topic: BIP 17 (Read 9220 times)