What happened to OP_RETURN? In bitcoin wiki it just says "Marks transaction as invalid." How could it satisfy any output? Has the definition changed?

Wait.....there is a big loophole. If subset generation and sig checking are decoupled, an attacker can use a signature for another transaction to redeem any outputs of the same script, because he can bypass those OP_PUSHOUTPUTWITHVALUE codes and feed the CHECKSIG with the subset hash of the previous transaction directly. I think that was the reason why Satoshi made OP_CHECKSIG doing everything.

It's easy, just a few more OP codes.

Generate tx subset (*):
OP_PUSHALLINPUTSWITHVALUE will return the concatenated hash, vout, and value of all inputs, by the order in the transaction
OP_PUSHTHISINPUTWITHVALUE will return the hash, vout, and value of this input
OP_PUSHALLOUTPUTSSWITHVALUE will return the concatenated output script and value of all outputs, by the order in the transaction
<bitmap> OP_PUSHINPUTWITHVALUEBYBITMAP will return the concatenated hash, vout, and value of the inputs specified by the bitmap
<bitmap> OP_PUSHOUTPUTWITHVALUEBYBITMAP will return the concatenated output script and value of the outputs specified by the bitmap
<x> <y> OP_PUSHINPUTWITHVALUEBYRANGE will return the concatenated hash, vout, and value of the inputs x to y inclusive
<x> <y> OP_PUSHOUTPUTWITHVALUEBYRANGE will return the concatenated output script and value of the outputs x to y inclusive
<z> OP_PUSHINPUTWITHVALUE will return the hash, vout, and value of input z
<z> OP_PUSHOUTPUTWITHVALUE will return the output script and value of output z
Then, use a new OP_JOIN to concatenate all these things (#)

Hash: use the existing OP_HASH256 to do double SHA256

Check sig: the new OP_CHECKSIG will verify the signature

(* This part could be further separated to something like OP_PUSHINPUT, OP_PUSHINPUTVALUE, but it will make it looks quite clumsy.)

(# By the way, why OP_CAT is considered as a high risk code and get disabled?)

here will be 3 ways to indicate the index: none (0x00), all (0x01), bitmap (0x02), and range (0x03)

To indicate inputs, "none" means "signing this input only", "all" means "signing all inputs, no more, no less"
To indicate outputs, "none" means "send to anyone", "all" means "all outputs are required, no more, no less"

01 01 is equivalent to the current SIGHASH_ALL
01 00 is equivalent the current SIGHASH_NONE
00 01 is equivalent the current SIGHASH_ALL + SIGHASH_ANYONECANPAY
00 00 is equivalent the current SIGHASH_NONE + SIGHASH_ANYONECANPAY


Bitmap and range are used when referring to some of the inputs/outputs

The bitmap code (0x02) is followed by some bytes. The length is determined by the number of inputs/outputs. For every 8 inputs or outputs, there is 1 byte. An input/output is indicated by "1" at the corresponding bit

The range code (0x03) is followed by 2 integers x and y to indicate the range of required inputs/outputs (x and y included). The integer is 1 byte if there is no more than 256 inputs/outputs, and 2 bytes if there is no more than 65536 inputs/outputs, etc.

The range code is less flexible, but more efficient if there is a huge number of inputs/outputs.

Number of inputs/outputs	Bytes for bitmap	Bytes for range
1-8	1	2
9-16	2	2
17-24	3	2
249-256	32	2
257-264	33	4
65529-65536	8192	4

I think the scheme could be simplified. There is no need to distinguish "sign a input" and "require a input". Signing an input that you own means you agree to release the fund. Signing an input that you do not own means you require that input to participate. It is illogical to say "I want my input to participate, but I don't want to sign it".

Back to my example,

Alice will construct this message: "Alice-1 Alice-2; A B C", take double SHA256, sign with her key (Alice-sig)*
Bob will construct this message: "Bob-1 Carl-1 ; D E", take double SHA256, sign with his key (Bob-sig)
Carl will construct this message: "Bob-1 Carl-1 ; <empty>", take double SHA256, sign with his key (Carl-sig)

Alice-sig is appended with this bitmap: 00000011 00000111. The first byte means she is signing for input 1, 2. The second byte means outputs 1, 2, 3 must be paid

Bob-sig is appended with this bitmap: 00001100 00011000

Carl-sig is appended with this bitmap: 00001100 00000000

Let me explain this way:

There are 3 key pairs: Alice, Bob, Carl
4 inputs: Alice-1, Alice-2, Bob-1, Carl-1
5 outputs: A, B, C, D, E

As long as outputs A, B, C are paid, Alice is willing to sign and don't care where other BTC comes from and where the rest of BTC goes
As long as outputs D, E are paid, and Carl-1 is involved, Bob is willing to sign and don't care where other BTC comes from and where the rest of BTC goes
Carl will sign if if Bob-1 is involved. He doesn't care where other BTC comes from and where the BTC goes

Alice will construct this message: "Alice-1 Alice-2; <empty> ; A B C", take double SHA256, sign with her key (Alice-sig)*
Bob will construct this message: "Bob-1; Carl-1 ; D E", take double SHA256, sign with his key (Bob-sig)
Carl will construct this message: "Carl-1; Bob-1 ; <empty>", take double SHA256, sign with his key (Carl-sig)

(* This is simplified. The actual message is <Alice-1 hash><Alice-1 vout><Alice-1 value><Alice-2 hash><Alice-2 vout><Alice-2 value><separator><separator><Output A script><Output A value><Output B script><Output B value><Output C script><Output C value>)

However, the transaction is not compete yet.

The raw, unsigned transaction is arranged this way:

Input index 1: Alice-1
Input index 2: Alice-2
Input index 3: Bob-1
Input index 4: Carl-1

Output index 1: A
Output index 2: B
Output index 3: C
Output index 4: D
Output index 5: E

Alice-sig is appended with this bitmap: 00000011 00000000 00000111. The first byte means she is signing for input 1, 2. The second byte means she doesn't care where the rest of inputs comes from. The third byte means outputs 1, 2, 3 must be paid

Bob-sig is appended with this bitmap: 00000100 00001000 00011000

Carl-sig is appended with this bitmap: 00001000 00000100 00000000

<Alice-sig-bitmap> <Alice-public key> OP_CHECKSIG2 is used as the scriptsig of input 1 (just like P2SH)
OP_1 OP_PUSHSCRIPTSIG is used as the scriptsig of input 2 (2 bytes only. saved a lot of space!)
<Bob-sig-bitmap> <Bob-public key> OP_CHECKSIG2 is used as the scriptsig of input 3
<Carl-sig-bitmap> <Carl-public key> OP_CHECKSIG2 is used as the scriptsig of input 4

The tx is completed. Broadcast.

--------
To verify:

Input 1: Based on the bitmap of Alice-sig (00000011 00000000 00000111), we can reconstruct this message: "Alice-1 Alice-2; <empty> ; A B C". Take double SHA256, verify the signature against Alice-public key
Input 2: Scriptsig of input 1 is used. Repeat the verification. (In an optimized system such repeat is not needed)
Input 3 and 4: Similar to input 1

As all signatures are valid, the transaction is valid.

4bytes = 32bits = 2^32, not 32

I choose 4 bytes because now we use 4bytes to encode vout

Oh I'm sorry. You are right. That's easy, just use a variable length integer (https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer ) to encode the number of bytes of the bitmap.

(Don't need an extra byte to encode because the number of inputs/outputs is known by looking at the transaction)

For large transaction this could become very big. We may allow people to assign a range instead.

REVISED:

There are some complaints about the existing CHECKSIG procedures:

1. Choice of SIGHASH types are restricted. It is either all or one or none, but cannot sign some of the outputs. (https://bitcointalk.org/index.php?topic=212555.0)

2. It wastes a lot of blockchain space to sign outputs of the same script, because it requires one sig per input

3. In order to calculate the fee, one needs to see the full transactions which could be a problem for lightweight hardware wallet (https://bitcointalk.org/index.php?topic=181734.0)

4. It has some unexpected behaviors: https://bitcointalk.org/index.php?topic=260595.0

To solve these problems, we need to revolutionize the way of checking signatures. Here I propose the OP_CHECKSIG2

The format of signature is completely different for OP_CHECKSIG2. In human language, the signature will look like:


This structure will supersede all existing sighash types (all/none/single/anyonecanpay), and do a lot more

------------------------------

Some definitions:
Input index: order of an input in a final transaction. The first input is index 0
Output index: order of an output in a final transaction. The first output is index 0
OutPoint: <hash of previous tx|output index of previous tx>. A 36 bytes identifier of previous outputs, describe at https://en.bitcoin.it/wiki/Protocol_specification#tx
InputID: An unique identifier for an input, in a format of <value of the input|OutPoint> (36+8=44bytes)
OutputID: <value of the output|pk_script length|pk_script>, same format as TxOut describe at https://en.bitcoin.it/wiki/Protocol_specification#tx


Some new OP codes:
OP_EVAL2:

• Pop the second-to-top stake (a)
• Calculate HASH160(a)
• Pop the top stake (b)
• If HASH160(a) is not equal to b, the script fails
• Deserialize a, and run it as script

OP_CHECKSIG2: it pops the top 3 stakes <sig> <hash> <public key>, and check the validity of <sig> against <hash> with <public key>. If it is, 1 is returned, 0 otherwise.

OP_PUSHINPUT: it pops the top stake. From the top stake, it pops the least significant byte. If the least significant byte is:

• 0x00:
  • The script fails if the remaining string is not empty
  • Returns InputID of the input
• 0x01:
  • The script fails if the remaining string is not empty
  • Returns InputID of all inputs in a concatenated form by the order of input index, with Input 0 at the beginning.
  • Appends a 0xff at the end of the concatenated string
• 0x02:
  • Enumerate the number of inputs, divide by 8, round up to the next integer if not an integer.
  • The script fails if the length (in bytes) of the remaining string is larger than the integer.
  • Read the remaining string as a bitmap. Each bit refers the an input, with the least significant bit refers to input 0.
  • If there is any positive bit for an non-existing input, the script fails.
  • For every positive bit, returns the InputID of the corresponding input by the order of input index.
  • Concatenate the results, with the InputID of the lowest index at the beginning.
• 0x03:
  • Enumerate the number of inputs, take log₂₅₆, round up to the next integer if not an integer.
  • The script fails if the length (in bytes) of the remaining string is not equal to 2 times the integer.
  • Split the remaining string in half. Call the more significant halve x and the less significant halve y.
  • If x>y, the script fails.
  • If y is greater than the largest input index, the script fails.
  • Return the InputID of all inputs with index from x to y (inclusive) in a concatenated form by the order of input index, the InputID of the lowest index at the beginning.

OP_PUSHOUTPUT: it pops the top stake. From the top stake, it pops the least significant byte. If the least significant byte is:

• 0x00:
  • The script fails if the remaining string is not empty
  • Returns an empty string
• 0x01, 0x02, 0x03: Same as OP_PUSHINPUT, just replace inputs with outputs.

OP_PUSHSCRIPTSIG:

• Pops the top stake, an interger (z >= 0)
• The script fails if z is greater than the highest input index
• Return the ScriptSig of the input z

To make this a soft-fork, OP_EVAL2 and OP_PUSHSCRIPTSIG will use some of the unused OP_NOP (e.g. OP_NOP3 and OP_NOP4); The other new codes will use currently unspecified codes, and they will fail the script if not called by OP_EVAL2

For example, in a standard transaction, the ScriptSig would look like (in a bitmap mode):


scriptPubKey would be:


Running the script

• 1. stake = <sig> <0x1802> <0x0C02> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2> <hash of serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 2. OP_EVAL2, stake = <sig> <0x1802> <0x0C02>
• 3. OP_PUSHINPUT, stake = <sig> <0x1802> <concatenated InputIDs for inputs 2 and 3>
• 4. OP_SWAP, stake = <sig> <concatenated InputIDs> <0x1802>
• 5. OP_PUSHOUTPUT, stake = <sig> <concatenated InputIDs> <concatenated OutputIDs for outputs for outputs 3 and 4>
• 6. OP_CAT, stake =  <sig> <concatenated InputIDs and OutputIDs>
• 7. OP_HASH256, stake = <sig> <hash of concatenated InputIDs and OutputIDs>
• 8. stake = <sig> <hash of concatenated InputIDs and OutputIDs> <public key>
• 9. OP_CHECKSIG2, stake = <1>. Script ends.

-----------------------

To prepare a signature:

• List the InputID of all required inputs (including inputs to be signed by the key pair, and any required inputs owned by other key pair)
• Concatenate the InputID, by the desired order
• Append an 0xff at the end if the exact inputs are required (no more, no less)
• List the OutputID of all required outputs
• Concatenate the OutputID, by the desired order
• Append an 0xff at the end if the exact outputs are required (no more, no less)
• Concatenate the InputIDs and OutputIDs, take double SHA256, sign with private key

-----------------------

To prepare a transaction:

• Arrange the order of inputs and outputs to make sure they are coherent with all signatures
• ScriptSig will be <signature> <command for OP_PUSHOUTPUT> <command for OP_PUSHINPUT> <serialized script>
• If a key pair is signing for 2 or more outputs, the ScriptSig for the rest of inputs is simply <input index> OP_PUSHSCRIPTSIG

------------------------

Example of a full transaction:

There are 4 key pairs: Alice, Bob, Carl, David
5 inputs, the InputIDs are: Alice-1, Alice-2, Bob-1, Carl-1, David-1
5 outputs the OutputIDs are: A, B, C, D, E

As long as outputs A, B, C are paid, Alice is willing to sign and don't care where other BTC comes from and where the rest of BTC goes
As long as outputs D, E are paid, and Carl-1 is involved, Bob is willing to sign and don't care where other BTC comes from and where the rest of BTC goes
Carl will sign if Bob-1 is involved. He doesn't care where other BTC comes from and where the BTC goes
David will sign if all 5 inputs and 5 outputs are involved. No more, no less.

Alice will construct this message: "Alice-1|Alice-2|A|B|C", take double SHA256, sign with her key (Alice-sig)*
Bob will construct this message: "Bob-1|Carl-1|D|E", take double SHA256, sign with his key (Bob-sig)
Carl will construct this message: "Bob-1|Carl-1", take double SHA256, sign with his key (Carl-sig)
David will construct this message: "Alice-1|Alice-2|Bob-1|Carl-1|David-1|0xff|A|B|C|D|E|0xff", take double SHA256, sign with his key (Carl-sig)

The raw, unsigned transaction is arranged this way:

Input index 0: Alice-1
Input index 1: Alice-2
Input index 2: Bob-1
Input index 3: Carl-1
Input index 4: David-1

Output index 0: A
Output index 1: B
Output index 2: C
Output index 3: D
Output index 4: E

The ScriptSig for input 0: <Alice-sig><0x0702><0x0302><serialized script>
The ScriptSig for input 1: OP_0 OP_PUSHSCRIPTSIG
The ScriptSig for input 2: <Bob-sig><0x1802><0x0C02><serialized script>
The ScriptSig for input 3: <Carl-sig><0x00><0x0C02><serialized script>
The ScriptSig for input 4: <David-sig><0x01><0x01><serialized script>

The tx is completed. Broadcast.

-------------------------------------

Evaluating inputs with OP_PUSHSCRIPTSIG:


scriptPubKey would be:


Running the script

• 1. stake = <0>
• 2. OP_PUSHSCRIPTSIG; stake = <sig> <0x0702> <0x0302> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 3. stake =  <sig> <0x0702> <0x0302> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2><hash of serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 4. OP_EVAL2, stake = <sig> <0x0702> <0x0302>
• 5. The rest is same as above

If properly optimised, these steps are actually not needed,  saving many hashing and ECDSA operations

OP_MAST_EVAL sounds like an extension to BIP17 or BIP12. Isn't it? Very interesting

I just realize that it could be a soft-fork. Actually, any new OP code could be soft-fork (https://bitcointalk.org/index.php?topic=255145.msg2757327#msg2757327). So we just need a OP_CHECKSIG2 that will recognize the new rules.

If the key is never used, I can't see any risk with this. The merchant will eventually see tx1. If the merchant is not satisfied with tx1 or tx2, they will not acknowledge tx1 and not use the key again

But anyway, I always love the idea of OP_PUSHBLOCKHEIGHT. This has been discussed many times here. It simplifies the process a lot and could be wrapped as P2SH. User can keep sending bitcoin to the same P2SH address without those timelock txs.

I am just not sure how it could be done as a soft-fork. I think a soft-fork new OP code could only be "nothing or fail". Unless you wrap it as a serialized script and run it with a re-defined OP_NOP, and make it looks like send-to-anyone to old clients, i.e.

The merchant doesn't need to see the full tx1 before he signs tx2. He just needs the hash of tx1 and the corresponding output index. If the merchant uses a brand new private key, he can blindly sign the tx2:

1. Merchant sends a new public key (Pu-M) to user

2. User creates a transaction (tx1) to send bitcoin to 2-of-2 multisig of Pu-M and Public key of user (Pu-U). DO NOT BROADCAST

3. User creates a timelock transaction (tx2) to send the multisig output of tx1 back to himself; sign it; pass it to merchant

4. Merchant signs tx2 WITHOUT KNOWING tx1

5. User sees the fully signed tx2. Broadcast tx1

6. Merchant acknowledge the tx1 after several confirmations

These SD discussion is just shit.

It is not possible to sell 10000BTC without moving the price. Even worse, it is not possible to withdraw fiat from gox, and the volume of bitstamp and btce just can't support big sell. If Erik and his team want fiat, it's much better for them to sell SD for fiat or fiat + BTC.

Sorry I don't understand


OP_DEPTH "puts the number of stack items onto the stack." What's its function here?

https://bitcointalk.org/index.php?topic=258311.0;topicseen

1. 請確認你用的是0.5.12

2. 如果你是經URI打開multibit, 有可能是舊版本

3. 你的交易最少需要0.0002費用

視乎有沒有礦工幫你處理. 如果一兩天內都沒處理, 你有可能可以再發, 但我不知道multibit的設計.

I am not MultiBit user. I am reporting a problem of a Chinese user. He uses 0.5.12 to create this tx: 5ed5a26683ad83d0fed3938d8424c2568da7ca0490edb47029acaf82e8d2afd4 . It is not confirmed for hours due to the change value is smaller than 0.0000543.

我會幫你匯報問題. 但要處理那交易就比較麻煩

不會. 這只會令你最終付兩次款. 你用的是multibit什麼版本?