Bitcoin Forum
May 04, 2024, 06:27:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 [7]
121  Economy / Speculation / All-time-high volume on: January 25, 2013, 03:20:48 AM
Just some of you may not realize, we have broken the all-time-high volume in USD at the gox USD market yesterday. It was $3.053M and also the only trading day >$3M

It was always the third trading day with >$2.5M. The first one was 2.859M on 8 Jun 2011, during the first bubble. The second one was 2.93M on 17/08/2012, after pirate default
122  Economy / Speculation / Are we going to climb over the ask wall and see $17/BTC today? on: January 21, 2013, 04:06:00 PM
High ATM: $16.98

I think many people read this article, The Rise and Fall of Bitcoin

http://www.wired.com/magazine/2011/11/mf_bitcoin/all/

The article was published on 23 Nov 2011, when bitcoin was trading at $2.3, following a catastrophic fall from $31.9.

It mentioned that "the bitcoin never got back above $17". It's true even up to now. Are we going to climb over the ask wall and see $17/BTC today?
123  Economy / Speculation / Impact of ASIC on price on: January 14, 2013, 05:23:02 AM
Many people think the arrival of ASIC will have impact on BTC price because the ASIC buyers will dump their BTC to recoup their investment on ASIC. First of all, I seriously doubt if this may happen because the buyers should be the most hardcore bitcoin believers, which would be more likely to hoard than dump.

However, just assume the worst case. For Avalon, they are selling 300units with $1300 each, ie. $390,000 totally. Assuming the miners want to fully recoup the $390,000, they need to dump about 28,000BTC and push the price down to about $13.61 (based on the current bid wall).

Please remember this is only the worst case. Since only 3600BTC is generated per day, the 28,000BTC will be generated in 8 days even Avalon takes over 100% of the network. Recently there are many 10,000BTC dumps and the market recovered very soon. Selling BTC3600/day for 8 days will be negligible. Not to mention some AISC owners may decide to hoard rather than dump.
124  Bitcoin / Bitcoin Discussion / bitcoin.org and weusecoins.com in other languages on: January 07, 2013, 02:39:56 PM
Today I read a Chinese blog discussing bitcoin: http://blog.qq.com/qzone/622007907/1341497503.htm

The most interesting part is the reader's comment: 5 out of 20 comments complain that they can't read the English websites.

According to wikipedia, Chinese is the most widely spoken language in the world, followed by English and Spanish. The number of Chinese internet users has surpassed the total population of the US. For historical and technical reasons the web is dominated by English. As a global and decentralized currency, however, bitcoin should serve the needs of non-English users.

Therefore, I propose the 2 major entry websites: bitcoin.org and weusecoins.com should be fully translated to non-English languages. I can do the Chinese translation, and other volunteers will work on other languages. As this will appear on the "official" websites, the translations should be peer-reviewed to make sure they are properly done.

I will start working on it if this is approved by the devs who are controlling the domain names.
125  Economy / Gambling / An effective attack against SatoshiDice on: January 03, 2013, 04:24:18 AM
I find an interesting transaction: http://blockchain.info/tx/9106ac6859097079d39127aaac86208ac2a2b9bade92c3ae109192b7bc340872

Paying 0.01BTC fee, it sent 228 x 0.000001BTC outputs to SatoshiDice. SD returned the fund (because they were lower than the minimum bet) with 228 transactions with 0.001BTC fee for each, with a total of 0.228BTC or about 3USD.

Comparing the loss of the attacker and SD, the ratio is 22.8x and seems quite effective. Actually there were 243 outputs in the attacking transaction (15 of them were not sent to SD) so the real ratio should be 24.3x. Since outputs do not contain public keys thus are small in size, I think 0.01BTC fee could actually pay for more than 243 outputs, making the attack even more effective.

So the question is, what could be the maximum harm done if the attacker paid 1BTC fee?
126  Bitcoin / Development & Technical Discussion / Order of inputs/outputs in transaction and order of transactions in block on: October 10, 2012, 02:58:35 AM
Assuming we have an unsigned standard transaction with 2 inputs (A, followed by B) and 2 outputs (C, followed by D). After the input A is signed, is it possible to alter the order of inputs or outputs without voiding the A signature? (Obviously we cannot alter the order of inputs / outputs AFTER the transaction is recorded in the blockchain since that will change the transaction hash and will be regarded as double-spend. My question is about altering the order before the transaction is broadcast, or when it is partially signed)

Similarly, when a correct nonce is found for a block, will changing the order of transactions within the block voiding it? (I guess it will since it should change the block hash. Just want to confirm)

Thanks!
127  Bitcoin / Development & Technical Discussion / Unique serial number for every single satoshi on: October 08, 2012, 04:19:03 PM
Although bitcoin is designed as fungible, it is possible to assign an unique serial number to each atomic unit (aka satoshi). With this serial number, a satoshi may represent more than its face value (e.g. colored bitcoin, smart property, securities).

Serial number has two parts: the integer part is the block number where the satoshi is generated, and  the fractional part represents each unique satoshi. Taking the generation at block 110000 as example:

http://blockexplorer.com/tx/4e10436ca8206a2dd760dd351210a5120a3824d4eb53011be0a7b9a33b368208

There were 50BTC, or 5000000000 satoshi generated. Therefore, the serial number of these satoshi are #110000.0000000001 to #110000.5000000000. Tailing zeros are reserved.

Here we define RULE OF INHERITANCE: In a transaction, the input sequence atomized to satoshi, with each satoshi has its unique serial number. The satoshi sequence is mirrored to the output, based on the output sequence. If transaction fee is paid (i.e. input > output), the fee is considered as the last output. In case of coinbase transaction, transaction fee is sorted after standard block reward, according to the transaction order in the block.

Using the previous example, the 50BTC is completely transferred to another address:

http://blockexplorer.com/tx/3abed8a3aa728e881a9ef85062fe11b79b490c885295c3c55fc6a534199a5dc5#i398943

Therefore, 12WFtKBsRLtV8p1NwRqe7YwYdi1rjwTZhA inherits satoshis #110000.0000000001 to #110000.5000000000.

Next, the 50BTC is split into two outputs: the first one with 5.2BTC and the second one with 44.8BTC:

http://blockexplorer.com/tx/2faea2cc59b32f5cc19fd8aee85db3e82bbdccb32c52879fecddc592b172d981#i399136

Therefore, the first output inherits satoshis #110000.0000000001 to #110000.0520000000, and the second output inherits satoshis #110000.0520000001 to #110000.5000000000.

The next one becomes more complicated. The 5.2BTC output in the previous transaction is mixed with other inputs. There were two outputs, with 0.36BTC and 60BTC respectively:

http://blockexplorer.com/tx/2ba980e8b17c46e671e8a09bef43815e26ae561facc35f415ef04b11bf4b7545#i405322

Based on the rule of inheritance, the first output will inherit the first 36000000 satoshis in the first input (bfdc71884b80...:0). All the rest will go to the second output. Those satoshis #110000.0000000001 to #110000.0520000000 are embedded somewhere in the middle of the second output. To be precise, they are the #2171000001st to #2691000000th satoshis in the second output. (5.11-0.36+5.49+5.3+1.15+5.02=21.71)

In the following transaction, the 60BTC is mixed with other inputs to make a single output of 954.27BTC

http://blockexplorer.com/tx/03616a5d76508d45a0def171c29b3672714410c49648704eb766f2e74b4ed1fe#i406741

Therefore, the satoshis #110000.0000000001 to #110000.0520000000 become the 81598000001st to 82118000000th satoshis of the output. (1.25+500+19+1+161.82+5.2+106+21.71=815.98)

Here we use another example with transaction fee:

http://blockexplorer.com/tx/afe357b19ca0b0c939b414d3dd63d523bb2a518237df51afc7d6f26098967c7d

Transaction fee of 0.00574567 (574567 satoshi) is paid. According to the rule of inheritance, transaction fee is the last output. The last 574567 satoshis of input comes from transaction bcf2b1c4f75c...:0, which is the generation of block 99120. Therefore, the transaction fee is satoshis #99120.4999425434 to #99120.5000000000

The fee is collected by the miner of block 100035:

http://blockexplorer.com/block/00000000000135cb86be36978e74a54cfd2b9143f827a589c9e27fde3463b753

Since this is the only transaction with fee in this block, those satoshis #99120.4999425434 to #99120.5000000000 are embedded at the end of the coinbase transaction. Therefore, the coinbase transaction has satoshis #100035.0000000001 to #100035.5000000000 and #99120.4999425434 to #99120.5000000000, in the exact order.

With this system, every satoshi has its unique identifier, or “color”. To make a lending contract, for example, the borrower will send a colored satoshi (e.g. #123456.1357924680) to the lender, and the lender will send the loan in the same transaction. The lender may sell the contract to other people with similar mechanism, and the borrower will repay to the address with the colored satoshi.

We can also have decentralized security market with the system. Each satoshi sent from the issuer’s address is equal to one share. Although the serial numbers of these satoshis may not be continuous, it is still traceable. The issuer will pay dividend to the addresses with colored satoshis, and the shareholders will vote using the address private keys.

Please note that this proposal has nothing to do with criminals/scammers tracing.
128  Bitcoin / Development & Technical Discussion / Transaction script with block height as condition on: October 03, 2012, 04:45:45 AM
I wonder if a transaction script like this would be allowed: If block height < x, use condition A; if block height >= x, use condition B

This could be very useful as trust-free, zero-confirmation exchange wallet

Assuming the exchange owns private key E, the user owns private key U, and x is the block height of near future (e.g. current block height + 10000), a transaction script would look like this: If block height < x, 2-by-2 multisig with E and U is required; if block height >= x, U is required. A script hash is derived

The user will comfortably send any amount of coins to this script hash. If private key E was compromised, no fund could be stolen. Even if the exchange operator disappeared (like Torwallet), the user could get the coins back after block x.

If the user wants to sell the coins before block x, he will sign a multisig transaction to send the coins to the address of key E (or any other addresses exclusively owned by the exchange). Since it is bound by the multisig requirement before block x, the user is not possible to double spend. Therefore, the BTC is readily available for trading with zero-confirmation.

To avoid the risk of double spend or Finney Attack, the multisig transaction should be signed by the user well before block x is generated, e.g. x - 10. After that, the exchange will not accept it by zero-confirmation. However, it will still accept it after 6 confirmations.

This also works for online wallet providers, stock market, marketplace, or Bitcoinica-type services. It won't totally eliminate the risk, but people could then deposit a large amount of BTC to these services and spend instantly at any time.

EDIT: For a bitcoin buyer, the exchange will send the freshly bought coins to the his script hash. Therefore, the buyer is also protected, while he could also sell the coins instantly.
129  Bitcoin / Development & Technical Discussion / Increasing the number of keys in key pool on: September 30, 2012, 08:03:27 AM
Again, someone lost >1300BTC due to misconception about wallet backup: https://bitcointalk.org/index.php?topic=110781.0

It might be difficult to implement deterministic wallet in the next release. However, it is very easy to increase the key pool from 100 keys to 10000 keys. Adding 2 or 0 zeros in the source code will solve 99% of the problem
130  Bitcoin / Development & Technical Discussion / Python code for private key --> address on: August 28, 2012, 05:09:03 PM
Is there any Python code that translates private key (in HEX format) to an bitcoin address? Thanks!
131  Bitcoin / Development & Technical Discussion / Reducing transaction size by merging signatures on: August 02, 2012, 09:18:44 AM
A standard 1-input 2-outputs takes around 258Bytes (e.g. http://blockexplorer.com/tx/8c58943f54a68c58a4ccb7038cb7fe0fc71d921082c932f81aaf723a045f9916). A multiple inputs transaction will take much more space (e.g. http://blockexplorer.com/tx/32dbc162003949c2a8eb494606f143c776b263bfec3dbfc59dff6e0dceb4fe51 ). In this transaction, however, all inputs are coming from the same address. Instead of using 12 signatures, is it possible to use one signature for 12 inputs? That would save a lot of space in long term.
132  Bitcoin / Development & Technical Discussion / Mining for transaction to improve system integrity on: May 11, 2012, 05:49:08 AM
I have an idea (not sure if it is a new one), so-called "mining for transaction", aims at dealing with the following problems:

1. Tx fee is required to prevent DoS attack. However, some people may not want to pay Tx fee. Particularly, if the tx amount is small (e.g. 0.0001BTC), the tx fee (now usually 0.005BTC) may exceed the tx amount

2. To avoid overhead, miners may not include any tx in their blocks (this did happen). Since tx fee is only a very tiny part of the mining bonus, this kind of unethical behavior is not punished and will hurt bitcoin economy

3. Currently, non-miners (bitcoin users who are not miners) have no position in blockchain development. This is not good because they should be valued as stakeholders of the network.

4. Currently, the only mechemism to adjust the block generation rate is by re-target for about every 2016 blocks. However, there is no mechemism to reduce the variation between rounds. Gaps between rounds could be only a few seconds with good luck, or much longer than 10 minutes with bad luck.

Objective:
1. To minimize tx fee while still preventing DoS attack
2. To encourage miners to include tx to block
3. To make the process of mining more decentralized by engaging non-miners in the mining process, hence reduce the risk of 51% attack
4. To provide a feedback mechemism to reduce the time variation between blocks

Definitions:
1. Priority has the same meaning in the current protocol -- as defined here: https://en.bitcoin.it/wiki/Transaction_fees . A tx with high priority means its input value is big, input age is old, and/or tx size is small

2. Tx hash, Block hash, Target, and Tx fee have the same meaning in the current protocol

3. Block bonus is the coins generated by mining, now 50BTC

4. Adjusted Tx hash (ATH) = (1 - x) + ((Tx hash * x) / (2^256 * Priority)), where x ranges from 0 to 1. For example, if x = 0.01, any adjusted Tx hash should range from 0.99 to 1

5. Adjusted block hash (ABH) = Block hash * ATH_1 * ATH_2 * ATH_3 * ...... ATH_N , where ATH_1 is the ATH of the first Tx in the block, N is the number of Tx in the block (ignoring the generation tx)

6. A block is vaild if ABH =< Target

------
By doing so, a tx-sender will mine for his own transaction (usually by CPU) before sending it to the network. A lower ATH is better, and there is no specific target. Miner will want tx with low ATH since they could reduce the ABH, which increase the likelihood of having a valid block (controlled by the value x).

x should be a fixed parameters, and x=0 is equivalent to the current protocol. The value of x should be small enough to ensure that the benefit from mining for transaction is less than that of mining for low block hash (otherwise people will mine for transcation and no one will mine for a block)

Alternatively, tx-senders may opt to pay traditional tx fee, instead of mining for his own tx (e.g. in case of using a slow computer). Or they may do both if they want to ensure instant acceptane by the network.

This protocol increases the cost of DoS attack by requesting proof-of-work and/or tx fee from tx-sender.

Since tx-senders will mine while usually they won't, this effectively increase the total hashing power of the whole network, lowering the chance of certain types 51% attack. It is now more difficult to prevent some or all transactions from gaining any confirmations, as the attacker will become less competative than honest miners. Also, it is difficult to invalidate historical tx as more mining power is needed to compensate the exclusion of historical tx.

Although the overall difficulty will be increased, it will be compensated by mining efforts from tx-senders and the de facto diffculty for miner should be similar to the current protocol. Bad miners trying not to include any tx will be punished as their de facto difficulty is higher than honest miners (more accurately: not lowered)

Feedback mechenism: At the beginning of a round, there is only a few tx on the waiting list and it is (relatively) more difficult to find a valid block. As the waiting list becomes longer, the de facto difficulty for the next block will be lowered by multipying many ATHs. This will reduce the likelihood of extremely good-luck and bad-luck rounds, and make the blocks more even distributed.

The only thing I am not sure is the choice of value of x. The system will collapse if the benefit of mining for tx is greater than mining for block. By the way, this article is conceptual and details (e.g. calculation of ATH, ABH and Priority) could be modified

If you like my idea, please send some tips to: 1Q8Ggvt13zrPdKNniPpCToHfTkSc5sgscW
Pages: « 1 2 3 4 5 6 [7]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!