Answer is clear: arbitrageurs

I think they explained: they dropped the rate after people trying to arbitrage. The rate shown is the current rate.

So my question is: what is the rate before adjustment?

Also an unanswered question: What about the price? Why didn't the volume spike move the price?

可能是blockchain.info根本沒有廣播出去. 等一下吧

So what about the price? Why didn't the volume spike move the price?

有人在英文板指控你們的交易量作假, 你們有沒有回應? https://bitcointalk.org/index.php?topic=262198.0

Is there any chance to support Lamport signature in the future? Comparing with traditional private key cryptography, Lamport signature is much more easy to implement. It is also QC hard. There are 2 major problems for Lamport signature: one-time-use only and large size.

The one-time-use only problem can be improved by using a merklelized public key (http://en.wikipedia.org/wiki/Lamport_signature#Public_key_for_multiple_messages).

For sig size, it's actually not that big. Using Hash160, the public key will consume 800bytes, and the signature will consume 400bytes, so the total will be 1.2kB (a few more bytes if merklelized public key is used). A transaction like this: http://blockchain.info/tx/8e17ed76cf51a9adcbb284365c2aff6bf28f7fa8259286dd1a93ec1cd47a81ca already takes 1.5kB. However, using the  CHECKSIG 2.0 I proposed at https://bitcointalk.org/index.php?topic=258931.0, it is possible to sign multiple inputs with only one signature. Therefore, using Lamport signature would not be a big problem.

嗯, 是我講錯了, 你們有一個bot專門把錢轉到離線錢包吧

是你自己玩SD弄成這樣的. 你還是好好學習一下bitcoin的原理

Making a bitcoin-spending bot without knowing how bitcoin works? It's just flushing your money to the toilet

如果只有提現認証, 但沒有security centre認証, 也是沒有用的

你們看不到, 但卻已經轉發出去: https://blockchain.info/tx-index/81962598

應該會有另一位客戶投訴收不到錢

是blockchain.info的bug吧. https://blockchain.info/tx/4de10bcf8a7967e5b98e6116a4bb5723c0371b3c52e85f5fa84e07d76eea47fb 你的這個交易沒有確認, blockchain.info又替你轉發出去, 當然不能確認

4de10bcf8a7967e5b98e6116a4bb5723c0371b3c52e85f5fa84e07d76eea47fb 付的費用不足, 基本上不可能得到確認. 無論如何你的84.27BTC還是很安全的, 但要弄回來就有點麻煩

796有嚴重的bug, 竟然把未確認的bitcoin轉發出去

Can we do this way:

• 1. Redefine OP_NOP1 as OP_MAST_EVAL
• 2. Format of scriptPubKey: <20 bytes script merkle root hash> OP_MAST_EVAL. (Any other data /OP codes in the script are invalid)
• 3. scriptSig: Pushing a single serialized script including all signature(s), hash(es) and script(s). Any other data / OP codes are invalid. This makes sure the script can't be edited after hash check (ref: P2SH)
• 4. There could be many sub-scripts for OP_MAST_EVAL. For example, if we want a 3-of-8 multi-sig. There will be 9 sub-scriptPubKey (sspk), numbered from 1-9.
  
  • The sspk2 to sspk9 are normal pay-to-public key scripts with different public keys:<pubKey-n> OP_CHECKSIG
  • The sspk1 is the main script, which will call the other sspk. To avoid looping (e.g. sspk2 calling sspk3 and sspk3 calling sspk2), only sspk1 may call other sspk.
  • Calling of sspk is done by OP_SSPK. It pops the top stake (the sspk-ID) and runs the sspk. Each sspk has its own sub-stake. No matter what is left in the sub-stake, OP_SSPK will only return either 0 (if the sspk failed) or 1 (if the sspk succeed) as top stake.(*)
  • For a 3-of-8 multi-sig, the sspk1 will be: <2> OP_SSPK <3> OP_SSPK OP_ADD <4> OP_SSPK OP_ADD <5> OP_SSPK OP_ADD <6> OP_SSPK OP_ADD <7> OP_SSPK OP_ADD <8> OP_SSPK OP_ADD <9> OP_SSPK OP_ADD <3> <OP_EQUAL>

• 5. Calculation of script merkle root is same as transaction merkle root, but done by hash160.
• 6. For example, we want use pubKey-2, 4, 5 to redeem the bitcoin. We need to provide these information:
  
  • Total number of sub-scripts (i.e. 9)
  • Full sspk1, sspk2, sspk4, sspk5
  • hash(sspk3), hash(sspk6), hash(sspk9), and hash(hash(sspk7) concat hash (sspk8))
  • sub-scriptSigs (sss) for sspk1, sspk2, sspk4, sspk5 (the sss1 is empty in this example)
  Concatenate all these things in a format without any ambiguity and push as the only item of the main scriptSig
  

• 7. OP_MAST_EVAL will
  
  • a. match the merkle root
  • b. run sss1 (which is empty here) with sspk1 (the whole transaction fails if sspk1 is not provided)
  • c. hit the first OP_SSPK, call sspk2, and run it with sss2, return a 1 when succeed
  • d. hit the second OP_SSPK, try to call sspk3. Since sspk3 is not available, a 0 is returned
  • e. keep running sspk1. The result of sspk1 is the final result

• 8. Failing of a individual sspk will not fail the whole transaction. It just pushes a 0 to the main stake.
• 9. All sspk must be called at least once in sspk1.

(* We may allow it to push the items in sub-stakes back to the main-stake. This allows greater flexibility but makes the system more complicated and may introduced unexpected behavior. I don't think it's necessary)[/list]

一看就知是英文寫成再翻譯

I am not a software engineer. I can't even read C++ code. But IMHO OP_CHECKSIG is just too complicated while not flexible. For each sighash type there is different procedure. With more procedure, there is higher risk of bug.

That's why I propose the CHECKSIG 2.0 ( https://bitcointalk.org/index.php?topic=258931.msg2768432#msg2768432 ). The logic of CHECKSIG 2.0 is simple: "I will release my fund from inputs a, b, c to outputs d, e, f, given that inputs h, i, j are also involved". Preparing subset, hashing, and signature check are separated into 3 OP codes, and it does not depends on OP_CODESEPARATOR. I think it is simpler and more flexible than the current CHECKSIG, easier to standardize, and less likely to have bug.

I have rewritten the proposal and defined the detailed behaviors of the new OP codes. I am looking forward to your comments

Currently, newly generated coins require 100 confirmations before it could be spent, since reward for orphaned blocks will never come back (if Gavin does not bail them out: https://bitcointalk.org/index.php?topic=156641.0  ). However, any transactions relaying on "anyone-can-take" outputs, such as

,

or


face similar level of risks. In case there is a block re-org, a miner may grab these outputs for themselves. Should we also flag any transactions without using ECDSA signature as generated coins?

I proposed something related but got moved to alt-coin section: https://bitcointalk.org/index.php?topic=257135.msg2739332#msg2739332

I find an interesting idea here: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas


It could be incorporated into CHECKSIG 2.0. To make it an optional function, I propose 2 new OP codes:

OP_JOIN: It keeps popping the stake, until the stake becomes empty or the top stake is -1. In the latter case, the -1 is removed. It returns the concatenated popped items (but not the -1). The first popped stake item is the beginning of the concatenated string.

OP_PUSHBLOCKHASH: Giving it a blockheight, it returns the block hash


Now the ScriptSig would be:



scriptPubKey would be:


So that the "<height> OP_BLOCKHASH" part is optional.

EDIT: It's different from the original idea. My proposal makes a transaction invalid if it is not mined in the designated chain. This seems not very good since it would become a big trouble in case there is network split / major re-org

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: basically the OP_EVAL of BIP12, but will run the now disabled OP_CAT and support some new OP codes
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 output
• 0x01, 0x02, 0x03: Same as OP_PUSHINPUT, just replace inputs with outputs.

OP_PUSHSCRIPTSIG:

• Pops the top stake, an interger (z)
• 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 will use one of the unused OP_NOP (e.g. OP_NOP3); 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>
• 2. OP_DUP, stake = <sig> <0x1802> <0x0C02> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 3. OP_HASH160, stake = <sig> <0x1802> <0x0C02> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2> <hash1>
• 4. stake = <sig> <0x1802> <0x0C02> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2> <hash1> <hash of serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 5. OP_EQUALVERIFY, stake = <sig> <0x1802> <0x0C02> <serialized OP_PUSHINPUT OP_SWAP OP_PUSHOUTPUT OP_CAT OP_HASH256 <public key> OP_CHECKSIG2>
• 6. OP_EVAL2, stake = <sig> <0x1802> <0x0C02>
• 7. OP_PUSHINPUT, stake = <sig> <0x1802> <concatenated InputIDs for inputs 2 and 3>
• 8. OP_SWAP, stake = <sig> <concatenated InputIDs> <0x1802>
• 9. OP_PUSHOUTPUT, stake = <sig> <concatenated InputIDs> <concatenated OutputIDs for outputs for outputs 3 and 4>
• 10. OP_CAT, stake =  <sig> <concatenated InputIDs and OutputIDs>
• 11. OP_HASH256, stake = <sig> <hash of concatenated InputIDs and OutputIDs>
• 12. stake = <sig> <hash of concatenated InputIDs and OutputIDs> <public key>
• 13. 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.