可以肯定你的bitcoin是安全的, 但要再發一次就會比較麻煩. 方法肯定是有的, 但我沒用過mutltibit. 其中一個可行方法是導出private key再另行簽署.

如果不懂複雜的技術操作, 你可以求求那些大礦主幫忙, 但也許要付些小費吧

你用的是什麼錢包

因為其中一個輸出少於 0.0000543, bitcoin 0.8以上預設不會處理.

你可以嘗試再發, 或求求那些礦主幫你處理

Headline : "The second largest Japanese bank is illiquid due to Bitcoin"

"CoinLab is the world's first US Venture-backed Bitcoin Company; it was funded in April 2012 by a group of progressive investors, including Tim Draper, Roger Ver, and Geoff Entress."

https://mtgox.com/press_release_20130228.html

 

This question is self-contradicting. How could one mine (in the normal sense) without any internet access?

I have discussed the solution for this problem at: https://bitcointalk.org/index.php?topic=248297.msg2634208#msg2634208

Here are the relevant parts:

1. Partial validating node with web-of-trust. Currently, there are 3 major types of bitcoin clients: full clients (e.g. bitcoind), SPV clients (e.g. bitcoinj), server-trusting clients (e.g. electrum). We can implement the 4th type: partial validating clients (PVC).

User may assign certain amount of system resources (CPU power / bandwidth / storage space) to bitcoind. If the node is unable to verify a block before the next block arrives, it will automatically turn into a PVC. Instead of verifying every blocks, a PVC will skip some of them. When a block is verified, a PVC will publish a signature for the block. Through a web-of-trust, people will be reasonably confident that the longest chain is a valid chain.

This could even be extended to mobile device. For example, a smartphone, which is normally running as SPV, may turn into a PVC when it is connected to AC power and wifi. Even only one block is verified per day, the network is strengthened as a whole.

2. Mining pools and full nodes on trusted platform. As some people are advocating centralized "bitcoin bank" running on trusted platform (TP), I think mining pool and public full nodes can also use TP. A full node on TP will accept new blocks and new transactions through encrypted channel, so that the network administrator won't be able to censor any block/transaction. They will also answer queries like normal full nodes but also in an encrypted way. With remote-attestation and fidelity bond (https://bitcointalk.org/index.php?topic=134827.0), it is very unlikely that the operator may cheat.

Based on TP full nodes, we can further establish TP mining pools. It's like a normal getblocktemplate mining pool so miners are free to construct their blocks, without doing any transaction validation themselves, assuming that the pool is trustworthy. Again, the integrity of the pool is secured by remote-attestation and fidelity bond. Therefore, mining will be decentralized even with huge block size. Mining over TOR is also possible.

Again, people will verify the integrity of TP full nodes with the partial validating nodes I described.

Please keep this discussion purely technical. There is no way in hell that ASIC miners will accept such change.

I am always thinking of a mixed proof-of-work alt-coin. It will involve 2 or more hashing algorithms, let's say SHA and Scrypt. A block will be either SHA or Scrypt, indicated by a new field in the header. There will only be one chain, which means SHA and Scrypt blocks will be linked together (it's like PPC). So the blockchain would look like
However, to mine consecutive blocks of the same type, the difficulty will be increased by 10%. On the other hand, the difficulty will be decreased by 10% if it is building on consecutive alternative blocks. In the above example, the difficulty will be:
The factor will have upper and lower limits of 1.5 and 0.5.

The difficulty change is determined separately for each hashing algorithms. For example, the difficulty for SHA mining is determined by the time span of the last 2016 SHA blocks, regardless of the number of Scrypt blocks in between.

Advantage of this system:

1. It's much more resistant to 51% attack as the attacker needs hashing power in multiple algorithms

2. Mining will be much more decentralised. We may use 3 algorithms: a strong Scrypt dedicated to CPU mining, SHA-3 suitable for GPU and FPGA mining, and SHA256 merged mined with bitcoin.

3. Breaking one of the algorithms won't break the system immediately, buying more time for a fix

4. It will also provide a feedback mechanism in case one of the block type is growing too slow or too fast. Jumping between alt-chains has become a big trouble because the difficulty won't decrease before next difficulty change. In the proposed scheme people will jump back when there is a difficulty discount and keep the chain moving.

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

Up to now, it's all about a alt-coin. However, I just realize that this could be done in bitcoin, with a soft-fork.

To make this a soft-fork, the backbone is still SHA256, while making some tricks in difficulty and include some extra data in coinbase.

1. Assume that we start with a traditional SHA256 block, with difficulty of z. We require that the next block will be an SHA256 block with difficulty of 2z. (since a higher difficulty is required, it is backward compatible)

2. Now we have a new SHA256 block of difficulty 2z. It correspond to the first SHA block in the previous example with difficulty x. Here we call it block A.

3. Scrypt miners start to build blocks on block A with difficulty y. The block will only contain a dummy coinbase transaction, specifying some outputs he wants. The sum of the outputs must be equal to or less than 50% of current block reward (i.e. 25/2=12.5 for now). Since this block is invalid for existing clients, no real bitcoin is generated in this process. Here we call this block B.

4. After blocks A and B are generated, there will be no restrictions on the hash type. Miners will build on block B.

4a. Scrypt miners will work on difficulty 1.1y. Again, the block will only contain a dummy coinbase transaction

4b. SHA miners will work on difficulty x. To make it backward compatible, the prevblock in header is pointing to the last SHA block (i.e. block A), while he has to put the hash of block B in coinbase. In the coinbase transaction, he has to distributed 50% of the reward to the earliest unpaid Scrypt block (i.e. block B) based on its dummy coinbase transaction. The SHA miner will also process transactions normally, and will keep the fee (*OOPS....I find a problem when I am typing this: what to do when block reward becomes smaller and smaller?)

5. If there is a long consecutive Scrypt chain, SHA miners will work on difficulty 0.5x = z, still backward compatible

6. Everything looks unchanged in the view of old clients, except that new blocks come 50% slower. However, this will be adjusted in the next difficulty change.

------------------
For obvious reasons ASIC miners will not accept a change like this (We might have a very slim but non-zero chance to do this before ASIC arrived and majority of GPU miners thought it was good). So this is a pure technical discussion. Just want to show how flexible the bitcoin protocol is and hope something really useful could be developed with similar schemes.

For *OOPS, we may distribute the fee the Scrypt miners (but it sounds not very fair). Instead of specifying the exact value in the dummy coinbase tx, Scrypt miners will specify the distribution in percentage.

Please don't just scream "no data in script". Provide some technical reasons for that.

There are so many data manipulating OP codes in script, so I don't think scripts were not supposed to store any data.

Whether we will need to worry about this, or whether we will become very rich, is irrelevant to this technical discussion

如果你正確使用, 不可能會丟幣. 我用64bit windows + 16G RAM, 幾天會出錯關閉一次但不影響使用

Since it is the ONLY place for it, so I can argue it is the BEST place for it.

Any old clients will work as usual without upgrade. They just can't send and receive sub-satoshi payment. There needs to be new block version and tx version for such upgrade. The client should give a warning when it sees a flooding of blocks and txs of unknown version, so people will know there are some new rules on the network.

Script is the only place to include arbitrary data and get signed. I can't see any other option without a hard-fork.

Had anyone tried to withdraw non-USD fiat with wire recently? (not SEPA)

There are many reasons to invest in an ETF rather than physical BTC. For example, hedge funds or pension funds may only be allowed to invest in listed assets. Investing in ETF may also fulfill the requirements of some business migration schemes. You enjoy the first class trading engine on NASDAQ, rather than the Magic the Gathering engine.

Why tx replacement is useful? There is no method to prevent miners mining a transaction with lower sequence.

Just like gold, in future bitcoin ETF will be traded in different stock exchange like London, Hong Kong, Tokyo. It seems someone is trying to setup one in Zurich

With soft-fork, miners are obliged to upgrade anyway because they have to follow the majority of hashing power. In a hard-fork, the fork may persist for a long time.

Non-mining old full-nodes will still work. It just can't do sub-satoshi transactions and turn into SPV-level security. However, SPV-level security is still much better than being left in an abandoned fork.

For SPV nodes like bitcoinj, nothing has changed. AFAIK bitcoinj is not even supporting P2SH and is still working.

你們是"中國最大"平台? 什麼最大? 說交易量你們每天只有幾百; 說吹牛皮又不及btc-gbl 

Increasing currency divisibility is listed as a hardfork in bitcoin wiki: https://en.bitcoin.it/wiki/Hardfork_Wishlist#Currency_changes

Actually it could be done with a soft-fork. (This is only for academic discussion. I don't think we will ever need to divide a satoshi)

1. Redefine OP_NOP1 as OP_PBTC (1pBTC = 1,000 nBTC = 10,000 satoshi)

2a. To mint pBTC, the total output value must be smaller than the total input value (let it be n satoshi)

2b. With n satoshi sacrificed, the user may, in the scripts of other outputs, embed this command
The sum of <amount>  must be equal to or less than 10000n

2c. Instead of taking n satoshi as fee, miner can only take not more than
So SUM(<amount>/10000) satoshi will be destroyed in the minting process

3. Transfer of pBTC follows existing rules: the total amount of pBTC in the outputs must be less than or equal to the total amount of pBTC in inputs. In the "less than" case, miner will take it as fee by embedding OP_PBTC in coinbase output(s)

4. In about 2049, the miner reward will drop from 0.09765625 to 0.04882812, with 0.5 satoshi lost. At that time, miners will be allowed to include extra 5000pBTC in their coinbase output(s).  

5. The effective value of an output is amount of satoshi + amount of pBTC/10000 .

6. It will not break existing clients, but they will underestimate the true value of an OP_PBTC output.

Notes:

1. Minting of pBTC is an one way process. It is not possible to "merge" 10000 pBTC to make it become a traditional satoshi again. This will be a hard-fork

2. pBTC is actually a special type of smart property/colored coin

3. Comparing with a hard-fork, there is at least 3 bytes of overhead (an OP_PBTC, an OP_DROP, and an extra OP_PUSH for <amount>). However, it is more economic than a hard-fork if there is no pBTC in output.

4. We will face the same miner reward problem again after a few reward-halve: 5000pBTC->2500->1250->625->312->156

5. With a similar scheme, we can further divide pBTC with soft-fork

So the customer can simply generate a big random number X, and request the miner to scan from X to X + 2^32. I can't see why this is weaker than hash of something