Bitcoin Forum
July 25, 2024, 12:44:00 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 »
1  Bitcoin / Armory / sign with input value on: January 05, 2016, 05:46:52 AM
etotheipi, I think this is what you are looking for:

This proposal defines a new transaction digest algorithm for signature verification in version 0 and version 1 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature.
2  Bitcoin / Mining / Please mine for BIP65, aka OP_CLTV / OP_HODL on: November 15, 2015, 06:38:04 PM
tl;dr OP_CHECKLOCKTIMEVERIFY (OP_CLTV) is the latest function in Bitcoin. It allows people to lock their money until a specified time. It enables many interesting use cases that were not possible / not safe, such as Lightning Network, trustless cross chain exchange (e.g. BTC <-> LTC) and micropayment channels. It is the most exciting new function added to Bitcoin Protocol since Satoshi created it in 2009.

Since the code allows people to freeze their money until a specified time, some people call it OP_HODL. For example, if you want to make sure you will hodl your coins until 2017, no matter it will go to $0 or $1million, only BIP65 would allow you to do it safely (without the need to delete your private keys)

What could you do?

1. If you are pool operator or solo miner: Upgrade to Bitcoin Core 0.10.4 or 0.11.2

2. If you are mining for a pool: Please urge your pool operator to upgrade. Please switch to BIP65 supporting pools, including (as of 2015-11-30):

BiscusFish / F2Pool:
Solo CKPool:
BitClub Network:

Please let me know if I do not mention your BIP65 supporting pool
3  Bitcoin / Development & Technical Discussion / A mistake in (Satoshi's github account) on: October 10, 2015, 03:58:29 PM
In , "Satoshi Nakamoto" is linked to the github account of saracen

However, is an active github account.

Is there anything wrong?
4  Bitcoin / Development & Technical Discussion / What is the status of BIP62? on: August 27, 2015, 04:42:30 PM
There are 7 new rules in BIP62:

1. Canonically encoded ECDSA signatures
2. Non-push operations in scriptSig
3. Push operations in scriptSig of non-standard size type
4. Zero-padded number pushes
5. Inherent ECDSA signature malleability
6. Superfluous scriptSig operations

1 has been deployed with BIP66.
2, 3, 4, 6, 7 are non-standard
5 is still allowed

Is there any schedule to deploy all the rules and what are the obstacles? Fixing malleability is very important for micropayment channels. Since we won't have a CHECKSIG 2.0 (as described in the Lightning Network paper) anytime soon, BIP62 is the easiest short term solution.
5  Bitcoin / Bitcoin Discussion / Big block support observer on: August 16, 2015, 05:52:15 AM
1. To follow the trend of big block approval / disapproval among full nodes
2. To follow the trend of big block approval / disapproval among miners
3. To follow the trend of big block approval / disapproval among major bitcoin economy players, holders, etc.
4. To discuss the strategy of soliciting support for big blocks (or otherwise)
5. This thread is not restricted to any specific big block client / BIP

1. Follow the number of big block supporting full nodes, e.g. BitcoinXX
2. Follow the number of big block supporting blocks, e.g. version 0x20000007, coinbase message
3. Follow credible news source, twitter/reddit/forum accounts
4. Proof of stake signature. If you hold bitcoins and would like to voice out, please sign a statement with your address with bitcoin. Instructions

1. This is a self-moderated thread. Posts violating the rules may be removed.
2. This thread is NOT for big block debate, including the discussion of pros and cons of different proposals and implementations. If you want to debate please go somewhere else. I believe there are plenty of places for this.
3. I don't want this tread being censored. Please avoid directly mentioning or linking any specific big block enabling bitcoin client. For sarcasm or not, call them BitcoinXX, Bitcoin**, BitcoinCensored, etc. Welcome to internet censorship (Based on the recent moderation style in this forum, this seems not necessary now)
4. No trolling
5. I will moderate more strictly if you have an ad-sig.

If you like this thread, please consider to donate a few mBTC to the address in my signature.
6  Bitcoin / Development & Technical Discussion / Ideas for a new block header format on: August 13, 2015, 05:07:07 AM
I just have some ideas for a new block header format.

1. Existing ASICs must survive the new format. Otherwise, miners won't agree to upgrade
2. To allow more information included in the header
3. Include height in the header so we could have a monotonic indicator in the header.
4. Headers not being too big for SPV clients

To archive all these targets a hardfork is needed

The header will have the following fields:
1. version (2): unsigned integer. Voting is moved to coinbase. 65536 versions should be enough forever.
2. prev_block (32): hash of the previous block
3. merkle_root (32): Root of merkle-sum-tree for fee, tx size, sigop counts, etc, so compact proofs could be produced for these parameters.
4. timestamp (5): unsigned integer. Enough for >34,000 years.
5. nonce (9): While a 1TH/s miner will exhaust 5 bytes of nonce in 1 second, we won't need longer nonce until miners become 4 billion times faster. (Current ASIC is only 1 million times faster than CPU, so we are taking about >1018 times faster than current CPU. This may happen only if SHA256 is partially cracked but then we need another algorithm)
6. coinbase (varint): the coinbase will become part of the header, which includes:
6a. height (4 currently): same as BIP34, consume 4 bytes for the following 300 years.
6b. bits (4): target in compact form
6c. arbitrary data: voting for fork proposals, merge mining, etc.

The max header size at the beginning is 160 bytes, which will allow 160-2-32-32-5-9-1#-4-4=71 bytes of arbitrary data.
(#To calculate the header size, the length indicator for coinbase is also counted)
The max header size is allowed to double every 4 years so more info could be included in the future.

Block hash is calculated as follow:

(* without length indicator)

In this way, the change is transparent to existing ASICs because they will still think they are hashing a 80-bytes header.
7  Bitcoin / Bitcoin Discussion / I ran Bitcoin Core for >3 years, and I turned it off today on: August 11, 2015, 06:08:10 PM
I ran Bitcoin Core for >3 years, and I turned it off today

I am now running Bitcoin**Censored**
8  Bitcoin / Development & Technical Discussion / Deleting abandoned UTXO on: July 21, 2015, 10:54:31 AM
There are some ways to limit the growth of UTXO set:

1. Discouraging creation of new UTXO --- fee and relay rules

2. Encouraging consumption of UTXO --- fee reduction and relay rules

3. Limit the delta-UTXO-size for each block --- softfork/hardfork

However, some small UTXOs may never be economic to spend, or the private keys are simply lost. I bet this is not a new idea but I think we should consider to delete those "abandoned" UTXOs.

That would be too controversial if we are trying to delete any existing UTXOs. Therefore, this proposal applies only to new UTXOs.

This is a softfork:

1. 0-value outputs are not spendable

1a. (variation) 0-value outputs must be spent within 5,000,000s

2. An output of 1 satoshi must be spent within 10,000,000s (3.8 months) after it is created. The creation time and the deadline are both determined by the block timestamp.

3. As the value doubles, the deadline is extended by 10,000,000s. For example, with 1.34217728BTC (2^27), the UTXO can stay untouched for 280,000,000s (8.87 years)

4. No interpolation: e.g., the deadline for 1.34217727BTC is 270,000,000s after creation. In practice, it just measures the length of value in binary with leading zeros removed, and multiplies the length with 10,000,000. The code should be simple.

5. Bitcoin in deleted UTXOs are lost permanently. Most commercial banks will just confiscate your money if the account is dormant for many (say 5) years. The blockchain bank, however, will just delete the record.

The initial value of 10,000,000s is chosen, so that assuming the extreme case of 1BTC = 1,000,000USD, an UTXO with 128 satoshi (1.28USD) will still have 2.5 years to spend. Anything with at least 327.68USD will have minimum 5 years of storage period.


The arguments for this proposal are:

1. Limiting the growth of UTXO set.

2. No one should assume that other people would store data for free indefinitely.

3. Stabilizing Bitcoin's value if we could prove some bitcoins are really lost.

4. The original "Bitcoin contract" is not violated if the proposal is not applied to existing UTXOs

The arguments against this proposal are:

1. It opens a Pandora's box of confiscating bitcoin

2. It will create more on-chain transactions as people are forced to move their bitcoin. Enough block size is needed to make sure people will not lose bitcoin due to lack of block size.
9  Bitcoin / Development & Technical Discussion / Reflections on the 4 July fork on: July 04, 2015, 06:51:29 PM
I think we can learn a lot from this lesson

1. Good practice of SPV mining?

SPV mining means mining without fully validating the previous block(s). Miners do that to reduce wastage of hashing power. I don't think prohibiting SPV mining is possible as we will never have 95% of miner support. If done properly, SPV mining is not particularly risky and could increase the overall hash rate of the network. Instead of trying to ban SPV mining, I think we should have a good practice guideline for SPV mining.

Miner should always validate the header, including the version, bits, and timestamp. There is no excuse to skip this. The laziness costs them 125BTC.

Building blindly on a valid header is fine, until the block is validated. The first confirmation of the original bogus block (363731) came after 13 minutes. It was more than enough for full validation and there was no excuse for the ignorance.

Miners should never extend an "SPV chain" to more than 2 (or 3 at maximum) blocks, even if that contains their own block. If an SPV chain is too long, they should assume it as invalid until it is fully validated. They should go back to the last known good block. This is to protect SPV wallets.

2. The 5 consecutive empty blocks

In the bogus fork, F2Pool and AntPool had a chain of 5 consecutive empty blocks. Although empty blocks are not uncommon, 5 in a row is suspicious. I guess there is some bugs in their system. For example, their system may insist to mine on their own blocks even if they are invalid (F2Pool and AntPool are alliance). And since the system knew the chain was invalid, it was unable to include any transaction.

3. Softfork voting by version bits

It is suggested that softfork voting should be indicated by bits in version, and allowing reuse of bits after the softfork is accepted or rejected. ( ) . I think this is the right way to go. However, in order to be compatible with SPV mining, the version bit should be kept switched on for 5,000 blocks after enforcement. This will be more than a month and should be enough to squeeze any laggards out. After that, the bit is free for another softfork proposal.

4. Wallet design

Full nodes should report which BIPs are they enforcing. SPV nodes should connect to full nodes with different rule set and compare their chains to identify any fork

SPV nodes should monitor recent forks. They should warn the users if there are long competing forks. They should consider transactions are unconfirmed unless they are included in both forks.
10  Bitcoin / Bitcoin Discussion / Blockchain split of 4 July 2015 on: July 04, 2015, 02:52:54 AM
F2Pool is building on a wrong side and there is fake confirmation since block 363731. (EDIT: the bogus chain of 363731 is already orphaned and not relevant to normal users)

If you use light weight wallet or old version of Bitcoin Core, you should stop accepting bitcoin for a moment

EDIT: For people looking for latest advice, please see the header of the forum. If you see no warning in the forum header, you may assume business back to normal

EDIT: More details:
11  Bitcoin / Development & Technical Discussion / (Unrelated to block size) Hardfork/P3SH proposal: OP_RETURNTRUE on: July 02, 2015, 10:28:53 AM
In the upcoming block size hardfork, I would propose to have a relatively simple change by introducing a new OP code: OP_RETURNTRUE

When the script engine reads an OP_RETURNTRUE, it will evaluate the script as valid immediately, regardless of what happens after that.

OP_RETURNTRUE is a "non-push OP code" in BIP62. Putting a bare (non P2SH) OP_RETURNTRUE in the scriptSig will immediately invalidate the script.

We may have OP_RETURNTRUE1, OP_RETURNTRUE2, OP_RETURNTRUE3, etc as long as we have enough unassigned OP code.


OP_RETURNTRUE is useful if we want to introduce new OP code to manipulate the stake. For example, if we want to reintroduce OP_CAT, it is not possible to do it with OP_NOP because it doesn't allow rewriting of the stake content. Currently, the only way to introduce OP_CAT is by a new version of P2SH.

With OP_RETURNTURE, we can directly redefine it as OP_CAT, and it will instruct the script to concat the top 2 stake items. Since the new OP_CAT does not return a true directly, this must be a softfork by definition.

We may even redefine those unused OP_NOPs into OP_RETURNTUREs. Because OP_RETURNTURE can do everything that an OP_NOP may do. (We can turn an OP_RETURNTURE into OP_NOP with a softfork, for example)


If this OP_RETURNTURE reminds us the nightmare of CVE-2010-5141 (, I would suggest to turn those unassigned OP codes into OP_NOPs (still a hardfork). It will defer the needs of using double bytes OP codes


EDIT (2015-Sept-1): This could be a softfork, if we put it into "P3SH". This will defer the needs to have a new version of P2SH every time we want a new stack manipulating OP code.
12  Bitcoin / Development & Technical Discussion / Record breaking block: 363270 on: July 01, 2015, 04:13:43 AM

This block has 4509 tx with exactly 1,000,000 bytes, both are new record. It is also the only block with more than 4000 tx
13  Bitcoin / Development & Technical Discussion / Partial validating nodes on: June 29, 2015, 10:55:38 AM
With increase in block size, it will become more difficult to run a full node. However, SPV nodes may still contribute by validating some, but not all blocks.

Based on my estimation with not-so-random sampling of blocks, I assume:
3 inputs per transaction on average
550 bytes per transaction on average

Also, 1kB = 1000 bytes, 1MB = 1000kB.

With 8MB block, that would be 14545 tx / block. To locate a tx with 14545 tx / block that would require 14 levels of Merkle hash, i.e. 14*256/8 = 448 bytes / input

So an SPV proof for each input would take 550 + 448 = 998 bytes. Lets round it to 1kB.

With 14545 tx / block, that means 43636 inputs / block. Therefore, for a partial validating node to validate a 8MB block (assuming inputs are valid), it has to download 8MB + 43.636MB = 51.636MB of data.

We currently have around 5900 full nodes. Since partial validating nodes does not need to store the block data permanently, we may have at least 10,000 partial validating nodes in the future. With each node validating only 1 block per day, each of the 144 blocks in a day will be independently validated by 69 nodes.


To further extend the idea, partial validating nodes may sign the validated blocks. With some kind of web-of-trust system people may validate the blockchain collaboratively


Even mobile devices may become partial validating nodes when they are connected to AC power and WIFI. It may take a few days for them to validate a single block but it still contributes to the network security as (hopefully) there will be many mobile devices with SPV wallets.


What happens if an invalid tx is found? A fraud warning system is tricky because that could become a DoS vector. We may require fraud warning to be signed by bitcoin address with a certain amount of deposit. This would be a different topic.

14  Bitcoin / Development & Technical Discussion / 60% of hashrate including 2 major exchanges agree to raise block size to 8MB on: June 18, 2015, 03:53:03 AM
5 largest mining pools in China, including 2 of the busiest exchanges in the world, release a joint declaration to support raising the MAX_BLOCK_SIZE to 8MB. They currently control 60% of the network hashrate.

Chinese companies are operating under a very oppressive environment. All internet activities are strictly censored and outbound bandwidth is limited. They still agree to increase the block size.

Although one may argue that on this issue merchants' view is more important than miners, the hardfork won't be successful without miners' support. And don't forget, this statement includes 2 major exchanges, BTCChina and Huobi.

I hope this would conclude the debate around "raise block size or not" and "how much to raise".

I hope we could focus on the pathway leading to 8MB. Should that be a simple raise or a step function? If a step function, how? Should we limit other parameters, e.g. sigop count and UTXO growth?

The hard fork should also consider the pathway beyond 8MB if we don't want to repeat the debate (too early).
15  Bitcoin / Development & Technical Discussion / Rounding error in calculation of chainwork on: May 26, 2015, 04:07:38 AM
At block 356831, the chainwork reported by Bitcoin Core is 06f293e337e48534b58620. However, I find that the actual expected value should be 06f293e337e48534b7d080, which is 150,112 bigger than the one reported by Bitcoin Core.

In Bitcoin Core, the work each block is underestimated by 0.5 hash on average due to rounding down, and therefore ~150,000** in total at current height.

150,112 hash is nothing, of course. But I think this would affect the way we determine the longest chain and a fix would be a hardfork?

**(The problem did not exist in the first 32,256 diff=1 blocks. The actual number of affected blocks is 324,576 and the expected difference is 162,288 vs actual difference of 150,112. The effective sample size is 161 targets and I think the discrepancy is within statistical error)
16  Bitcoin / Development & Technical Discussion / Softfork cutoff on: May 21, 2015, 06:36:23 PM
This are the current softfork cutoff rules:

75% rule: If 750 of the last 1,000 blocks are version X or greater, reject invalid version X blocks. (testnet3: 51 of last 100)
95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version X or greater, reject all version Y (Y<X) blocks. (testnet3: 75 of last 100)

Isn't the 95% requirement an overkill? It allows a few % of miners to indefinitely hinder a softfork.

If the requirement is reduced to 900/1000, it is still almost impossible for 87% of miners to achieve (probability=0.2%). So in the worst case, we would temporarily waste up to 15% of hashing power while they will be forced to upgrade immediately. No non-upgrading full nodes will be fooled as the probability for the 13% minority to have 6 blocks faster is only about 0.1% (as calculated by Satoshi in the white paper)

Making it as 1800/2000 will be even safer
17  Bitcoin / Development & Technical Discussion / How is UTXO currently stored in Bitcoin Core? on: May 09, 2015, 02:14:32 PM
I get the following gettxoutsetinfo output:

"height" : 355650,
"bestblock" : "00000000000000000fd87566bb5527cc1580f7c7c2afdde34797d3072f616d3e",
"transactions" : 5622974,
"txouts" : 19127223,
"bytes_serialized" : 685867123,
"hash_serialized" : "7aaaa95a2a74edf337a89d93907324d4bfb7abf423ee9a484caf3af6e506ad79",
"total_amount" : 14141114.77930497

So it's 685867123/19127223 = 35.86 bytes/txout

However, 35.86 bytes is merely enough for storing the size of scriptPubKey (1 bytes) + std P2PKH scriptPubKey (25 bytes) + value (8 bytes)

So where is the data for the 36 bytes outpoint (txid + index)?
18  Bitcoin / Development & Technical Discussion / Should we just remove the wallet function of Bitcoin Core on: May 08, 2015, 04:11:39 PM
Just see another victim of the 100-address trap in the Chinese subforum. 10BTC lost. Comments in the thread say the best option for noobs is to use a centralized bitcoin bank. I just feel speechless and don't want to argue with them

Should we just remove the wallet function of Bitcoin Core if HD is not (read: will never be) implemented? If people want to be a full node, they can use Armory. Otherwise, they can use Electrum.

Actually, wallets without deterministic backup (e.g. Bitcoin Core) should not be recommended in

19  Bitcoin / Development & Technical Discussion / What is the optimal block size? on: May 08, 2015, 04:02:10 PM
Let's have some thought experiments.

m = Max Block Size

The very minimal size of a bitcoin block would be around 250 bytes, which will allow nothing but only a standard coinbase transaction. No one will agree to have m=250B because Bitcoin like this could only be a mechanism to timestamp a hash.

How about m=500B? That will allow one real transaction in each block, in addition to the reward. May be it would be enough to allow transactions between 2 or 3 users. But if there were only 2 or 3 users, we won't even have a Byzantine General problem. Mining is just a waste of resources.

Similarly, no one will agree with m=1k, 2k, or 10k. Bitcoin in such form may support transaction within a very small group but has no practical utility as a global payment network

Conclusion 1: there must exist a size x, when m < x, Bitcoin system would have no practical value and people would use something else. Different people may have a different value of x in mind but there should be a reasonable range. For example, Satoshi thought that x will be =< 1MB for a certain period of time, so he put the cap as 1MB.

On the other hand, we may have a Bitcoin network to record all transactions of all creatures in this galaxy, with m = GoogolplexB. However, only the Inter-galactic Payment Network Federation may be able to run it, exploiting the Hawking radiation from the central black hole of Andromeda Galaxy.

By reducing m, thus limiting tps, running a full node will become more affordable.

Conclusion 2: there must exist a size y, when m > y, the level of centralization will make Bitcoin nothing better (or even worse) than a centralized payment system. Again, different people may have a different value of y in mind but there should be a reasonable range. For example, Satoshi thought that y was >= 1MB, so he put the cap as 1MB.

Conclusion 3: x will increase as the user number increase, as the number of tx thus demand of block space increases.


Conclusion 4: y will increase as time increase, with time as a proxy of technological advance. y might be 10kB in 1989 and 1MB in 2009


Conclusion 5: If x > y, there will be no possible value for m. Bitcoin is nothing but an academic experiment. That's why Bitcoin was not possible in 1989 but created in 2009. Satoshi is a genius but timing is equally important.


So the question is, what is the value of x and y in the coming few years?

I think it's easier to determine y. I think no one would think $1/month is not affordable. As Gavin# suggests that $5 could run an pruning^ full nodes with 20MB block, $1 should be enough for 4MB.* . And if we allow it to be $10/month, as I think many Bitcoin enthusiast are willing to pay, y is 40MB.

However, for the sake of consensus, let's say the very minimum value of y is 4MB at this moment. Anyone disagree?


Determining x is more difficult. It is a function of user number, while user number is a function of transaction cost, and transaction cost is a function of maximum block size. So it is sort of a loop.

x is also a function of the availability of off-chain system capacity. If we have a good off-chain system, x would be smaller.

But not being too aggressive, if we want to be 50% of Paypal which processes 11.6 million tx/day or 134tps, that will be roughly 70tps, which means 10MB##.

I'd say 50% of Paypal is really humble. Even if we have all alternative scalability solutions implemented, we still need to have enough room for on-chain tx.

So I would say x is 10MB, at least for a few years. Anyone disagree?


WAIT! So x > y and Bitcoin is a joke? Well, we are still far away from 50% of Paypal. Actually, the 1MB cap still works well at this moment with no one complaining confirmation delay. This suggests the current x is smaller than 1MB. In this regard, Satoshi made a good choice.


The final questions:

Should we schedule a block size increase in 2016? My answer is yes, because we can see x is increasing and will reach 1MB soon, and we are still well below y (4MB). As the hardfork process will take many months to complete, it will be too late if we initiate the raise after x is beyond 1MB.^^

What is the new size? I will support any proposal that's between 1 to 20MB but I don't think it should be smaller than 4MB, as the y estimated above. Actually there is no point to make it between 1-4MB because the "pain" of running a full node in this range would be similar.

^ well, you may argue that a REAL full node should not prune but it still monitors the network for any malicious miner activity can could warn all SPV clients
* Of course you can't buy a VPS with $1 but as the machine is not fully utilized you may do other things
## Don't forget 10MB is actually not enough for 70tps as blocks are created randomly.
^^ We did not have a problem when it hit the 250kB soft-limit in 2013, simply because that was a soft-limit and miner could easily response to it.
20  Local / 中文 (Chinese) / Bitcoin 要能夠容納更大的交易量 on: May 06, 2015, 06:14:00 PM
當 Bitcoin 在 2009 最初出現時, 其每個 10 分鐘的區塊最高可以有 32MB 容量, 換算約為每秒 200 項交易 (200tps, transactions per second). 但不久以後, Bitcoin 的發明人 Satoshi Nakamoto 為了防止系統被攻擊, 把限制降為 1MB, 自此 Bitcoin 系統最多只能處理 7tps. 相比支付寶的 1000tps 及 VISA 的 4000tps, 可謂微不足道.

Satoshi 原來的計劃是當系統變得更成熟後, 就會把這個限制放寬, 但他並未有做到這一點就消失了.

Bitcoin 的規則改動可以分為 硬分叉" 和 軟分叉" 兩大類, 前者涉及放寬規則, 後者則是收緊規則. Satoshi 當初把限制收緊為 1MB, 因此是軟分叉. 但如果現在要提升, 那就是硬分叉. 軟分叉只要大部份礦工支持就足夠, 但硬分叉則除了礦工外, 還要得到大部份用戶和商戶支持方能成功. 由於於寬容量涉及技術及經濟風險, 有關的爭論已經困擾社群多年, 一直沒有平息, 事情也沒有進展, Bitcoin 的交易量卻愈來愈接近每 10 分鐘 1MB 的上限.

最近, 比特幣基金會的首席科學家 Gavin Andresen 提出要在不久將來擴展 Bitcoin 處理交易的能力. 為此他會撰寫一系列文章, 以解釋為何我們有必要這樣做, 也要對反對者的意見提出反駁. 因為硬分叉需要大部份礦工, 用戶和商戶支持, 而眾所周知中國人正控制著相量份量的挖礦算力及交易量, 因此本人和 Gavin 溝通後, 會把相關的文章翻譯為中文, 讓更多人明白為何我們必需要增加 Bitcoin 的交易容量.

該系列文章會在 同步刊登, 該網站收錄了大量由本人原創的技術及評論文章.

本主題會由本人直接管理, 灌水回應會直接刪除.
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!