Bitcoin Forum
December 15, 2017, 01:06:01 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Using OP_CAT  (Read 4126 times)
sukhi
Newbie
*
Offline Offline

Activity: 12


View Profile
September 05, 2014, 07:01:40 PM
 #41

Code:
inputs: pubkey signature secret
OP_DUP <pubkeyA> OP_EQUAL
OP_IF <hashB> OP_ELSE <pubkeyB> OP_EQUALVERIF <hashA> OP_ENDIF
OP_ROT OP_CHECKSIGVERIFY OP_SWAP OP_HASH160 OP_EQUAL
That script is perfectly standard as a P2SH in current code.

Though I suspect you've confused the operation of the machine somewhat.


The script may be perfectly fine, but would bitcoin mainnet nodes broadcast transactions that contain that script?

I'd just like to emphasize that it is the core of my last post.  Can anyone answer that?
1513299961
Hero Member
*
Offline Offline

Posts: 1513299961

View Profile Personal Message (Offline)

Ignore
1513299961
Reply with quote  #2

1513299961
Report to moderator
1513299961
Hero Member
*
Offline Offline

Posts: 1513299961

View Profile Personal Message (Offline)

Ignore
1513299961
Reply with quote  #2

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

Posts: 1513299961

View Profile Personal Message (Offline)

Ignore
1513299961
Reply with quote  #2

1513299961
Report to moderator
1513299961
Hero Member
*
Offline Offline

Posts: 1513299961

View Profile Personal Message (Offline)

Ignore
1513299961
Reply with quote  #2

1513299961
Report to moderator
1513299961
Hero Member
*
Offline Offline

Posts: 1513299961

View Profile Personal Message (Offline)

Ignore
1513299961
Reply with quote  #2

1513299961
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1148


View Profile
September 05, 2014, 10:32:27 PM
 #42

I'd just like to emphasize that it is the core of my last post.  Can anyone answer that?

There is a plan that P2SH will effectively accept nearly all scripts.

https://github.com/gavinandresen/bitcoin-git/commit/7f3b4e95695d50a4970e6eb91faa956ab276f161
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L692

https://gist.github.com/gavinandresen/88be40c141bc67acb247

The limit is that your script must be less than 520 bytes and can't have more than 15 signature operations.

The update will presumably be in the next major release, since it is part of the main branch.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
sukhi
Newbie
*
Offline Offline

Activity: 12


View Profile
September 05, 2014, 11:43:20 PM
 #43

I'd just like to emphasize that it is the core of my last post.  Can anyone answer that?

There is a plan that P2SH will effectively accept nearly all scripts.

https://github.com/gavinandresen/bitcoin-git/commit/7f3b4e95695d50a4970e6eb91faa956ab276f161
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L692

https://gist.github.com/gavinandresen/88be40c141bc67acb247

The limit is that your script must be less than 520 bytes and can't have more than 15 signature operations.

The update will presumably be in the next major release, since it is part of the main branch.

Does that mean yes or no?

What does it mean and imply that it's part of the main branch?

Is there ETA for the next major release?
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352


https://www.realitykeys.com


View Profile WWW
September 07, 2014, 03:26:07 AM
 #44

If you really just want something conditionally redeemable by one person or another, I would recommend the transaction type I recommend for reality keys:

Reality keys will reveal private key A if a true/false fact is true, and private key B if it's false.

Alice and Bob want to make a contract to hedge the outcome of a fact because they each have opposing short positions relative to the fact.  Alice will be paid if the fact is true, Bob will be paid if the fact is false.

Reality keys publishes the pubkey pairs  a := gA ; b := gB

Alice has private key X and corresponding pubkey x, Bob has private key Y and corresponding pubkey y.

Alice and Bob compute new pubkeys  q:=x+a  and r:=y+b  and they send their coins to a 1 of 2 multisig of those new pubkeys, q,r.

The values q,r are zero-knoweldge indistinguishable from a and b unless you know x and/or y, so no one except alice and bob, not even reality keys can tell which transaction on the network is mediated by the release of A vs B.

Later, realitykeys releases A or B,  lets say alice wins.  She computes a new private key X+A, and uses it to redeem the multisig.  Bob cannot redeem the multisig because he knows neither X or B.

This looks like a perfectly boring transaction to everyone else. Alice and Bob collectively cannot be robbed by a third party, though they could be held up or if realitykeys conspires with Alice or Bob then there could be cheating. This risk could be reduced by using a threshold of multiple observers— which this scheme naturally extends to.

Sorry for hijacking the thread over this but just one thing to add on this pattern to avoid people getting into trouble - hopefully gmaxwell will correct me if I've got this wrong.

Since these x + a and y + b operations are invertible, you need to be careful that Alice doesn't know x, and Bob doesn't know y, until they've shown each other their own keys, a and b respectively. If they know the Reality Keys pubkeys in advance, it seems to be possible to make a special tricksy a or b key such that, when combined to make q or r, the owner could get the combined private key Q or R without knowing the relevant Reality Key private key X or Y.

See Alan Reiner's comment here:
http://permalink.gmane.org/gmane.comp.bitcoin.devel/4173

In theory it looks like everything should be OK as long as you don't register the Reality Key until after you've seen the other party's public key, but if you're able to avoid this restriction it would be safer; Not only do you have to make sure you do everything in the right order, you also have to rely on us (Reality Keys) keeping our public keys secret until after you've made the exchange. The public keys are indeed supposed to be secret until they're allocated, but they're harder for us to secure than the private keys, since we need to be able to give them out to people on demand in real time. (Also there are some benefits to the same keys being shared for multiple people's contracts, rather than being assigned uniquely every time.)

I suspect you could defeat tricksy key attacks by Alice and Bob each producing an extra private key, sending it to their counter-party and requiring them to combine it with their Reality Key in a non-invertible operation, but I'm too far out of my depth to assess this. (It might also have some privacy benefits, so I'd be interested to hear what knowledgeable people think.) For now when I've been building demo applications on Reality Keys I've gone with the non-standard branching transaction approach, since sending these transactions to Eligius is practical at the moment and they should become standard in the next major Bitcoin release.
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2366



View Profile
September 07, 2014, 07:17:29 PM
 #45

You just have to have alice and bob prove that they know the discrete logs of their own pubkeys (e.g. they sign a message with it while setting up their exchange). Work through the algebra and you'll see why.

If you have logs for #bitcoin from last year, I walked through the somewhat different pay to contract case, which is I think mostly what you're referring to-- in that case you alwas make the contract key G*HMAC(message,pubkey) to avoid someone setting their pubkey to an alternative contract.

Bitcoin will not be compromised
edmundedgar
Sr. Member
****
Offline Offline

Activity: 352


https://www.realitykeys.com


View Profile WWW
September 10, 2014, 02:11:03 AM
 #46

You just have to have alice and bob prove that they know the discrete logs of their own pubkeys (e.g. they sign a message with it while setting up their exchange). Work through the algebra and you'll see why.

Ah, sweet.

I guess we already fulfill this in my demo example (this script run with the --ecc-voodoo flag):
https://github.com/edmundedgar/realitykeys-examples/blob/master/realitykeysdemo.py
...because for convenience we have Alice and Bob temporarily queue up the funds that they intend to put into the contract transaction by paying to the hash of their own pubkey, so the contract transaction never happens unless they can both fund it by signing with the private keys of the pubkeys they've exchanged.

If you have logs for #bitcoin from last year, I walked through the somewhat different pay to contract case, which is I think mostly what you're referring to-- in that case you alwas make the contract key G*HMAC(message,pubkey) to avoid someone setting their pubkey to an alternative contract.

I haven't been able to find this so any more hints would be helpful, although I'm learning a lot wading through various IRC logs looking for it...
Pages: « 1 2 [3]  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!