It is well known that reusing the k in different signatures will leak the private key. The reuse of k is very obvious as the r for different signatures will be the same.

What about the case for BIP32 deterministic wallet? Let say an attacker knows the root public key and the chain code. If the private key holder signs 2 different messages using the same k, with 2 different addresses in the same (or different) branch of the deterministic wallet, is it possible for the attacker to detect it and deduce the private keys for the singing addresses (or even the root private key)?

Satoshi adopted the "output approach" in bitcoin, which means a transaction output must be fully spent, and different outputs of the same address must be spent separately. There are some known problems of this approach:

1. scriptSig malleability: Since reference to UTXO depends on the transaction hash, scriptSig malleability will break a chain of unconfirmed transactions.

2. Not optimal for micropayment. Since outputs are discrete, it is not economical to spend tiny outputs

Here I propose a different approach, the "account balance approach"

1. Only P2SH is accepted. The scriptPubKey is simply a script hash. People will send bitcoin to addresses, just like what we are doing now.

2. Instead of storing an index of UTXO, miner will store an index of non-zero-balance-address (NZBA). When an address receives a bitcoin, miner will either create a new entry in the NZBA set (if the address did not exist) or add the received amount to the corresponding address

3. To spend bitcoin, the private key holder has to provide a signature and a script, just like the current P2SH. In addition, the sender has to explicitly indicate the amount of bitcoin to spend

4. The sender will only indicate how many bitcoin is sent to a specified address. The sender doesn't care the final balance of the recipient.

5. When a miner sees a transaction, he will hash the script and look for the corresponding hash in the NZBA set. If the spent amount is not bigger than the balance of the address, the miner will verify the signature.

6. In evaluating the balance of an address, all unconfirmed transactions will be considered. Therefore, people could spend newly received bitcoin, as long as both receiving and spending transactions are included in the same block.

7. A block is valid as long as all scripts are valid and none of the address balance is negative

This is better than the current output approach because:

1. There is no reference to txid. scriptSig malleability won't invalidate a chain of unconfirmed transaction

2. It is optimal for micropayment. An address with 100,000,000 deposits of 1 satoshi will only occupy 1 entry in the NZBA set, and could be spent as 1 bitcoin with a single signature

3. Even without micropayment, it saves space because there won't be reference of txid (32bytes) in input. Instead, the transaction value is needed which takes 8bytes. So at least 24bytes are saved for each input.

4. Change output is not needed as a account balance could be spent partially.

5. If people do not want to reuse address for privacy reason, they can always completely spend the balance of an address and create a change, just like what we are doing now. (Space is still saved because txid is not used)

However, I'm not sure if the account balance approach is as computationally efficient as the output approach (in terms of memory use etc.) Also, I'm not sure with its implication to thin clients.

Any comments?

I had similar suggestions on Meta but that was totally ignored. I think I can get more attention here.

The current name "Development & Technical Discussion" is misleading. It can't reflect the purpose "Technical discussion about Satoshi's Bitcoin client and the Bitcoin network in general. No third-party sites/clients, bug reports that do not require much discussion (use github), or support requests." The current name attracts all those project and alt-coin development discussion and technical support requests.

and

http://www.business-standard.com/article/news-ani/bitcoin-chief-advises-to-invest-in-digital-currency-only-if-users-can-afford-to-lose-114030200294_1.html


I assume these are mistakes of some idiot journalists. But now the TBF should be aware of the mistakes. If they don't stop it, it is intentional deception.

I'm not TBF member. TBF members please bring this message to your internal forum.

Just an extension of this discussion: https://bitcointalk.org/index.php?topic=486133.0

Script is one of the most important elements in bitcoin, but it is far from perfect. Several codes were disabled due to bugs. OP_CHECKSIG is not upgradable. Do we even have a chance to have Script 2.0? This is the Script 2.0 in my mind:

1. It has to be backward compatible, aka soft fork. Thanks to Satoshi, this existing Script will allow us to do so by redefining one of the OP_NOP as something like OP_SCRIPT2EVAL

2. It has to be fully upgradable: it should retain enough room for future upgrade, in case we want Script 3.0, 4.0, 5.0. This is simple

3. Support merklized abstract syntax tree (MAST). This will allow very complex redemption conditions and embedding secret messages, while saving a lot of space.

4. Support multiple public key algorithms, allowing n-of-n multisig with n different public key algorithms. Since it is extremely unlikely for breaking different algorithms at the same time, funds are safe forever.

5. Support more hashing algorithms. Same as 4

6. OP_CHECKSIG should be broken down into several codes. It should allow the signer to specify the value of the input so lightweight wallet can calculate the fee without knowing the details of the previous tx. It should have enough flexibility to let people decide the way to sign. I had other preliminary ideas here: https://bitcointalk.org/index.php?topic=258931.0

7. The new OP_CHECKSIG has to take tx malleability in mind. It should allow people not to specify the txid of input (signing any UTXO of the same address), or sign the normalized txid. With normalized txid supported, however, it means full nodes have to keep an index of the normalized txid of all UTXO

8. It may allow pushing the block height and block hash to the stake. Pushing block height may allow something not doable with nLockTime (I'm not very sure). Pushing block hash will allow users to specify the fork which they want their tx being mined (something like POS. not sure if this is really useful)

EDIT: 9. It should allow the use of shorter hash and public key. This will be very useful for micro-payment and short-term storage.

The problem is, having a Script 2.0 like this could be risky. We may need to create a new alt-coin to test it for a long time before it could be merge to bitcoin. Any comments?

Here I assume the "Crisis Strategy Draft" is authentic, as suggested here: https://twitter.com/paulbuitink/status/438428157948219392 . That means it requires 742408 BTC to cover Mark's ass.

Question 1: How do you acquire 742408 BTC? It's nearly 6% of all the existing bitcoin. Satoshi is probably the only person who holds such amount but I can't imagine he would bail out gox, nor sell a single satoshi to you. You may buy such amount from multiple early adoptors but you need to spend at least $0.22 billion for the deal even at a rate of $300/BTC

Question 2: Whether you buy the coins from Satoshi, from other early adopters, or your good self is Satoshi, you are releasing 6% of all bitcoin from dead cold wallet. That equals to 200 days of mining revenue and 5 times of FBI's holding. Do you think releasing such an amount in no time will cause a big chaos and crash in the market? How could you prevent this?

Question 3: If you have 742,408 BTC (whether you will buy it or already own it), why would you think you can earn more than this amount from gox in foreseeable future? With 1% fee you need a volume of 74,240,800 BTC to earn this amount. With 10,000 BTC per day, it will take you 20 years to recoup your investment. New markets are emerging and some have much lower fee, so I won't be surprised it would take >100 years to recoup your investment, if ever

Question 4: Taking 10% of your 742,408 BTC you can build the most solid exchange ever. You will attract all serious traders very soon. Why do you need the gox brand?

Question 5: Have you considered all the legal consequence of taking up a company with ongoing lawsuit with CoinLab and US DHS, and possibly the Japanese government?

Question 6: Have you considered the possibility that someone has taken all the 742,408 BTC and claims it was lost due to a security hole? How could you disprove this theory given the anonymous nature of bitcoin? For me this theory is much more plausible than someone kept draining the cold wallet and did not realize the problem until it became empty.

---------------------
My comments:

To be honest my biggest concern is question 2. The market cannot absorb such a huge amount if it is released in no time.

Of course, all these questions are based on the 742408 BTC assumption. If the amount is more reasonable, like 20,000 BTC, that could be a good deal.

Declaration: gox owes me nothing

http://zh.scribd.com/doc/209050732/MtGox-Situation-Crisis-Strategy-Draft

This document claims that gox is holding 624408 of customers' BTC. It's like 5% of all existing bitcoin. I think this is ridiculous as there was always less than 50000 on the order book. Why people are storing huge amount of money on gox for nothing? I simply can't believe it.

(here I mean the liability, not the actual amount of BTC in gox's wallet)

http://two-bit-idiot.tumblr.com/post/77760399932/update-on-mt-gox-this-document-appears-to-be

This document claims that gox has lost 740,000 BTC and has only 2,000 left

This sounds really ridiculous. 2000BTC could not even cover 10% of the ask wall on gox. How could Mark not realize it far before the cold wallet becomes 0?

2015-11-04:

UPDATE

Name of this thread is changed to "BETI: Bitcoin Exponential Trend Index and technical analysis". It will not only include a regular update of the BETI, but also general technical analysis and observations.

BETI = ln (daily VWAP / exponential tread expected price)

For example, on 2015-11-02, the VWAP was 347.89 and the expected price was 1848.06. BETI = ln (347.89/1848.06) = -1.670

Data source and calculation of the expected price are described below

Please consider to donate if you like this service

-------------------
2014-02-17:

Starting from today, I will offer a regularly update of the bitcoin long-term exponential trend.

Method:

Data source: bitcoincharts.com daily volume weighted average price (VWAP)

Reference exchange:
  17 Jul 2010 to 18 Jun 2013: MtGox
  19 Jun 2013 to now: Bitstamp

Dates omitted:
  20 Jun 2011 to 25 Jun 2011 (MtGox closed)
  6 Jan 2015 to 8 Jan 2015 (Bitstamp closed)

Regression model:
  y = ax + b,
  where y = natural logarithm of VWAP; x = days since MtGox inception, 17 Jul 2010 = 0; a = slope; b = intercept

Glossary:
  Rsq: R-square value of the regression model
  Today's expected price: The expected price of today based on the regression model
  Predicted date for today's price: The expected date for today's price based on the regression model
  Days ahead (behind): The difference between today and the predicted date for today's price. A positive value indicates we are currently above the regression and vice versa
  Daily price rank: The rank of today's VWAP among all historical VWAP. 1 means the all-time-high VWAP

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

Date: 16 Feb 2014
VWAP = 625.45
x = 1310
a = 0.006037
b = -1.82098
Rsq = 0.871816
Today's expected price = 440.0484
Predicted date for today's price = 15 Apr 2014
Days ahead = 58
Daily price rank = 84
Predicted date for ATH ($1126) = 26 Jul 2014
------------------------

tl;dr:

ASSUMING the bitcoin price is growing with an exponential trend in long-term:

We expect bitcoin price to grow by about (1 - e^a) = (1 - e^0.006037) = 0.6055% per day
87.1816% (Rsq) of the variation in bitcoin price could be explained solely by time (which is very high)
The long-term "fair" price of today is only 440.0484. We are outpacing the long-term trend.
We expect to see today's price (625.45) on 15 Apr 2014, which is 58 days later
We expect to see ATH (1126) on 26 Jul 2014
Today's price is the 84th highest in the history of bitcoin

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



y-axis is ln(price)
Blue line is the daily VWAP
Red line is the expected price of the day. For each day, a regression is fitted with all data of and before that day, so it is not a straight line.
Green line is the current regression line

I don't really expect this will be implemented, but I hope people will find this interesting.

Transaction structure is the same but an extra field, txSize, is added. Transaction hash is the hash of everything with scriptSig removed, and this is the hash going to the Merkle Root. As the scriptSig will not go to the Merkle Root, it won't be really recorded in the blockchain. People can freely mutate the scriptSig (even after confirmation). Miners will accept a transaction if they see a valid scriptSig and the transaction size is equal to txSize. This will make sure the block size is not mutable.

Payer could opt to sign the txSize or not.

This could be a hardfork, or a softfork with the auxiliary block: https://bitcointalk.org/index.php?topic=283746.0

Any comment?

The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.

請轉載至各大中文網站, 作者: bitcointalk.org jl2012, 捐款地址: 1CiZPrEJdN4FJcqdLdgVLzT8tgCXxT5ion

原文為英文, 也是我寫的: https://bitcointalk.org/index.php?topic=458386

假設我們有一所"比特幣銀行", 人們可以在銀行開設賬戶, 並得到賬號 (比特幣地址), 可以往賬戶存款, 也可以用支票轉賬

Gox在比特幣銀行開設很多賬戶, 因此有很多不同賬號. 對於每一位Gox客戶, Gox都給一個賬號. 因此Gox只要監察所有銀行賬戶, 就可以知道哪位客戶給他們存了款, 也就可以在對應的Gox賬戶入賬. 但請記著, 上述的銀行賬戶都是屬於Gox的, 因此客戶一旦存款到這些銀行賬戶, 錢就是Gox全權控制. 說到這裏, 相信大家都不陌生

當有客戶向Gox發出提現要求, Gox就會選擇一個銀行賬戶開支票; Gox為了證明自己已發出支票, 他們在發出前, 給支票拍照存檔. 正常情況下, 客戶拿著支票到比特幣銀行, 就可以兌現, 同時相關的Gox銀行賬戶就被清空了

但因為Gox的一些人為錯誤, 某些支票帶有一些污漬. 這些污漬其實無損支票的有效性, 但比特幣銀行的出納員 (礦場主人) 看著不喜歡, 所以這些支票很難兌現 (但我必須強調這些支票也是有效的). 因此有些客戶自行清理這些污漬, 然後就拿到錢了, 相關的Gox銀行賬戶也被清空

比特幣銀行是很公開的, 他們會把確認了的所有有效支票的照片公佈. Gox的會計把自己的支票照片和比特幣銀行公佈的照片一一比對. 但因為支票送到比特幣銀行時已被清理乾淨, Gox就找不到相同的紀錄, 他們也就誤以為相關的銀行賬戶仍然是有錢的. 當另一客戶要求提現, Gox便嘗試用這些實際上已被清空的銀行賬戶發出支票. 結果比特幣銀行當然不會接受這空頭支票, 也就是這幾星期很多客戶投訴比特幣提現不到賬的原因

更麻煩的是, 有些客戶看中了Gox的漏洞, 在清理支票並拿到錢後, 仍然向Gox投訴支票不到賬. 由於Gox自己賬目混亂, 又在比特幣銀行的紀錄中找不到自己發出的支票的照片, 便把錢退回客戶的Gox賬戶. 因此客戶便白賺了, 損失的是Gox. 必須強調比特幣銀行絕對沒有損失, 即沒有所謂"雙花" (double-spending)

現在Gox就指控比特幣銀行, 指他們不應接受這種經過清理的支票. 他們甚至指所有交易所都面對相同問題

Gox現在提出, 人們不應比對支票照片, 而是比對支票號碼, 因為支票號碼是獨一無二而且不能修改. 他們要求比特幣銀行同意這做法, 然後才會重新開放提現

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

首然, 這問題3年前已經發現, 一直在解決中, 但絕不是一個緊急問題. 現實中的支票在某些情況下, 改動了也無損有效性 (例如沾上少許污漬), 但改動了付款人/收款人/金額等資料就會令支票無效. 比特幣交易也是一樣

那麼, 其它交易所, 以至標準比特幣客戶端 (bitcoin-qt) 是如何處理這問題? 他們根本不會比對照片, 而是直接監察銀行賬戶結餘. 因此無論支票變成什麼樣子也沒所謂.

結論: Gox用了一個錯誤的方法監察賬戶, 出事了就指控比特幣銀行

Please keep this a technical discussion.

Gox proposes to use the hash of the signed string as a non-modifiable transaction id. Is it a good or bad idea?

I think for standard SIGHASH_ALL transactions this should work.

Let's assume we have a bank called "Bitcoin Bank". People can open accounts at the bank, get an account number (bitcoin address), and send money to their account. Money is transferred with cheque.

Gox opened many accounts at the Bitcoin Bank, with many account numbers. They give one account number to one customer. By monitoring these accounts, gox will know which customer has sent money to them, and credit to their gox account

When a customer submits a withdrawal request, gox will sign a cheque for one of its accounts at the bitcoin bank. They take a photo of the cheque, and use it as an evidence of delivery. However, some of the cheques issued by gox have dirt on them. Some customers cleaned the cheque first, then sent to Bitcoin Bank and got paid. The related gox bank account is then emptied.

Unlike a traditional bank, the bitcoin bank will publish the photos of all accepted cheques. Gox compares their photo records with the public records. Since the accepted cheque looks different from the original cheque (dirt is removed), gox can't recognize it and falsely believes that the related bank accounts still have money. Therefore, when another customer requests for withdrawal, they try to sign another cheque with the now emptied bank account. The Bitcoin Bank will reject this double spending cheque, and lead to all those withdrawal issues we have seen.

Even worse, some customers find the gox's bug and try to exploit it. After they cashed the cleaned cheque, they complain to gox saying that they have not received a cheque. Since gox can't find the cheque in the record of Bitcoin Bank, they credit the bitcoin back to the customer's gox account so the customer doubled his bitcoin at the expense of gox's fund (there is NO double-spending at the Bitcoin Bank)

So gox now blames the Bitcoin Bank that it should not accept the altered but yet valid cheque.

Gox also proposes that people should not trace a cheque by comparing photo. Instead, they should trace the unique ID of each cheque, as the ID is non-modifiable. They require the Bitcoin Bank officially endorse this practice before the re-open bitcoin withdraw.

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

So what is the practice of the standard bitcoin client (i.e. bitcoin-qt)? Instead of comparing the photo of cheque, bitcoin-qt actually monitors the account balance. Therefore, whether the cheque is altered is totally irrelevant.

Conclusion: Gox uses a WRONG way to trace transaction, and blame the Bitcoin Bank when everything is fucked up

Is there any easy way to broadcast non-standard transaction, more importantly, send to a miner who is willing to mine it? I think the blockchain.info API worked before but not now

BTC-E是各大平台中, 唯一可以提現為USD code的. 以後大家只需要在BTC-E交易, 然後在場外通過支付寶交易USD code, 那就根本不用理會什麼央行規定了.

https://bitcointalk.org/index.php?topic=372725.0

Someone just accidentally paid 20BTC as fee. I think we should make any transaction with >0.1 XBT fee as non-standard. (0.0001 XBT/kB * 1000kB = 0.1 XBT).

OT: This could be avoided if the blockchain.info API blocked the transaction.

The original announcement is here. I will translate it but please give me a few hours.

http://www.pbc.gov.cn/publish/goutongjiaoliu/524/2013/20131205153156832222251/20131205153156832222251_.html

In order to protect the property rights and interests of the public, to protect the legal status of the Chinese yuan, to prevent money laundering risks, and to maintain financial stability, the People's Bank of China, Ministry of Information Industry, China Banking Regulatory Commission, China Securities Regulatory Commission, and China Insurance Regulatory Commission jointly issued a "Notice on guard against the risk of bitcoin".

The "Notice" clarifies the status of bitcoin. It states bitcoin is not issued by a monetary authorities and is not a mandatory legal tender, and therefore is not a real currency. By its nature, bitcoin should be a specific virtual commodity, and does not have the legal status of currency, cannot and should not be used as currency on the market. However, general public may trade bitcoin on the internet by taking their own risk.

The "Notice" requires, at this stage, financial institutions and payment institutions may not denominate product or service in bitcoin, may not trade bitcoin, may not act as a central counterparty in bitcoin trading, may not offer insurance product associated with bitcoin, may not provide direct or indirect bitcoin-related services to customers, including: registering, trading, settling, clearing services; accepting bitcoin  or use bitcoin as a clearing tool; trading bitcoin with CNY or foreign currencies; storing, escrowing, and mortgaging of bitcoin; issuing bitcoin-related financial instructments; using bitcoin as a investment target for trusts and funds.


TBC

There are so many off-topics discussion on this board and it seems the mods are tired of cleaning it up. I think changing its name to "Bitcoin Protocol Discussion" would help a little bit

Since the BIT has stopped reporting the daily total assets value, it is not possible to update the table daily like before. Instead, it will be updated with a different style, mainly to show the actual or estimated Bitcoin holding the BIT. Previous data are still available at https://bitcointalk.org/index.php?topic=337486.msg3620848#msg3620848

Method:
1. Figures of Net asset value (NAV), total assets value (TAV), Total Share Outstanding, and XBT per Share are taken from http://www.bitcointrust.co/ or http://grayscale.co/bitcoin-investment-trust/
2. Total XBT holding = Total Share Outstanding * XBT per Share

* XBT is the unofficial ISO4217 code for bitcoin (http://en.wikipedia.org/wiki/ISO_4217#Without_currency_code)

** Estimated figures are subject to rounding error.

*** Negative figures could be due to rounding error.

Valuation	NAV	TAV	Total	XBT	Total
Date	($)	(M$)	Share	per Share	XBT
20151231	40.65	60.01	1,476,500	0.09556465	141,102
20151130	35.89	51.36	1,430,800	0.09572712	136,966
20151030	31.15	44.36	1,424,200	0.09588987	136,566
20150930	22.73	32.13	1,412,000	0.09604763	135,619
20150831	22.04	31.10	1,410,800	0.09620565	135,727
20150731	27.48	38.74	1,409,500	0.09636921	135,832
20150630	25.31	35.58	1,405,500	0.09653305	135,677
20150531	22.86	32.11	1,404,800	0.09669187	135,833
20150430	22.46	31.32	1,394,600	0.09685626	135,076