你發了25個帖全部都是btc008, 還好意思說自己無意轉發. 你還是換過另一馬甲再來吧  |
|
|
|
So the engraver will see my public address and my private key with a few changes. Are there any risk of my coins getting stiolen?
Yes, absolutely. So forget it |
|
|
|
jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.
Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE. For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works. More complicated changes, e.g. merkle sum tree, will break SPV nodes |
|
|
|
By definition, soft-fork means making currently valid block invalid, hard-fork means making currently invalid block valid. However, I think soft-forks could be further divided into 4 levels. "Level I soft-fork" will only affect miner. An example of level I soft-fork is the recent upgrade to v2 block. Upgrade is optional for non-miner. If they don't upgrade, their effective security will decrease to SPV level. However, they can still enjoy the full functionality of bitcoin. Developers of alternative SPV clients do not need to take any action. "Level II soft-fork" will introduce new functions to bitcoin. Examples of level II soft-fork are P2SH and my proposal for native colored coin support ( https://bitcointalk.org/index.php?topic=253385.0) Upgrade is still optional for non-miner. If they don't upgrade, they won't be able use the new function. However, they can still use Bitcoin the currency as usual. Developers of alternative SPV clients do not need to take any action if they don't want to support the new functions. Actually, most SPV clients are still not supporting P2SH. "Level III soft-fork" will introduce currency changes to bitcoin. Examples of level III soft-fork is the OP proposal and my proposal for further currency divisibility ( https://bitcointalk.org/index.php?topic=256516) Upgrade is still optional for non-miner. If they don't upgrade, they will have some troubles in transacting with new nodes. However, they can still spend and receive "old bitcoin" as usual. If SPV clients do not upgrade, the users will have the said trouble. "Level IV soft-fork" will denial some or all existing services. Non-miner could only either follow the new rules or follow a hard-fork. Although by definition this is a soft-fork, politically and practically it is very similar to a hard-fork. Any aux-block softfork would be at least Level III because it will introduce aux coins that are invisible to existing clients. That might not be as easy as we think. EDIT: I find an interesting point. When there is a hardfork, the original fork will become a de facto Level IV softfork, because the original fork 1. has stricter rules, and 2. denials to serve any transactions related to the hardfork. So we shouldn't exaggerate the power of a high level soft-fork. |
|
|
|
早就揭發了這個騙子網站, 你不識好歹在這投機, 能全身而退是你走運, 還想有人捐款給你? |
|
|
|
|
I have one more question for gmaxwell: how do you deal with the divisibility of the off-chain coin? It seems the off-chain coins are transferred like smart properties, which means that they are indivisible. If one tries to divide a coin in the off-chain system, there is no guarantee that the fractions will reunite in the future, making them permanently locked in the off-chain system. Therefore, people need to mint off-chain coins with different denominations for daily use. However redeeming a low value coin may not be economically viable due to relatively high bitcoin miner fee.
|
|
|
|
So I don't see what exactly the merchant gains from waiting for block confirmations instead of just quering the oracle directly and instantly.
The purpose of block confirmations is moving coins between different external systems, paying some who doesn't want to use those systems (because they do have a different security model than Bitcoin), etc. I think he's referring to my lately proposed system Although there is only one "timestamp miner", i.e. the oracle, in my proposed system, the timestamps list is made public and everyone can verify. Although the oracle won't do any PoW, it can't trivially rewrite historical timestamps because they are buried in the bitcoin blockchain. So basically, it has the same security level of bitcoin: everyone can verify, and protected with SAME amount of PoW. Since the timestamps list is merely a list of hashes, there is no privacy concern. The merchant will verify that there is no replay in the current and all previous timestamps. The future ones are irrelevant because the system will always favor the first owner of the off-chain coin. For the rest of jtimon's questions, I think gmaxwell has answered. |
|
|
|
I have an idea to combine the blockchain-based and anti-replay oracle schemes for a stronger model. 1. The oracle will create an UTXO on the bitcoin blockchain and announce it to the world. (the "initial UTXO") 2. The oracle will collect timestamping requests from users. The requests are in the form of {HC,SHB} (as defined in OP). The oracle will accept a timestamping request only if it has never seen something beginning with the same HC before 3. With all timestamping requests collected, a Hash Merkle Root ("HMR") is calculated. 4. Using the initial UTXO as input, the oracle will create a transaction with only one output (the "second UTXO"), with a script like: OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG <HMR> OP_DROP 5. Before the transaction is mined, the oracle will update the transaction if it receives more timestamping requests. It will pay more fee to encourage miner to accept the updated transaction. (There is no big deal if an old version is mined. Just some people need to wait for the next block) 6. When the transaction is mined, the oracles will publish all timestamped requests. 7. The oracle will use the second UTXO to create a new timestamping transaction. The procedure is repeated, making it a chain of time stamps. 8. Usually there should be only one timestamping transaction in a block. After a blockchain re-org there could be more than one such tx in a block. But this is okay since the sequence is always clear. On the user side: 1. When a merchant receives an off-chain coin (as described in the anti-replay oracle in OP), he will not deliver the product until he finds that the off-chain coin is timestamped in the blockchain with at least one confirmation. He will also check the hashes lists of the current and ALL previous timestamping transactions to make sure there is no replay. He will deliver when he is satisfied. 2. The merchant won't need to keep monitoring the future timestamping transactions. Instead, he will just monitor the bitcoin blockchain to see if someone is trying to redeem the SCIP-locked bitcoin. (Such redemption should not be possible unless the oracle replays) 3. We may have a separate P2P network to distribute the hash list, and use something like bloom-filter to allow light nodes to verify its newly accepted off-chain coins. The SCIP-locked bitcoin: 1. The SCIP-locked bitcoin is redeemable with a proof of the full transcript (as OP suggest), PLUS the SPV links showing that the transcript is buried in the blockchain. 2. Using CoinCovenant, the SCIP-locked bitcoin is sent to another SCIP address. If it is not challenged by other people, the bitcoin could be sent to a normal bitcoin address after a timeout. 3. If the oracle replays, the first owner of the off-chain coin (the merchant in the last section) will find the redemption attempts on the blockchain. Now he will publish his transcript, with SPV links showing he is an earlier owner, and sends the SCIP-locked bitcoin to another SCIP address. Again, if it is not further challenged by other people, the bitcoin could be sent to the merchant's normal bitcoin address after the second timeout. -------------------- This system is better than the original anti-replay oracle scheme because the bitcoin blockchain provides an undeniable proof of timestamp sequence, so the SCIP could judge who is the original owner. |
|
|
|
You can charge them a flat fee, say 0.0005BTC
But who's to say that will actually be enough to cover the miners fee? What about handling of this problem for alt-coin clients as well? Is there no way to query what the client will generate as the miners fee in advance? A flat rate, if high enough, should cover the fee on long term. If you really want to tell the user the exact fee before transaction, you should do it this way: 1. User tells you the amount he wants to withdraw 2. You search your UTXO set, find suitable UTXOs, calculate the fee and you tell the user 3. You lock the chosen UTXOs for a few minutes (not to be used in other tx) 4. If the user accepts the fee, you will proceed |
|
|
|
|
You can charge them a flat fee, say 0.0005BTC
|
|
|
|
|
The casino is not handling bitcoin properly
|
|
|
|
Anti-replay oracle based
Alice has a digital coin: coin={Value, Alice's pubkey, transcript of the coin's history}, and wants to assign it to Bob.
Bob tells Alice Hash(bob's pubkey)=HB.
Alice computes Hash(coin)==HC, and also Sign(HB)==SHB.
Alice contacts a trusted anti-replay oracle, telling it {HC,SHB}.
The oracle returns Sign({HC,SHB}) if and only if it has never signed something which began with HC before.
Alice passes this information on to Bob, along with the coin. Bob checks the coin's history and is satisfied that he has a valid coin which has not been double-spent.
This can be continued on and on, passing a coin from party to party, producing an ever-growing transcript. It can be trivially extended by using M of N anti-replay oracles, or other similar improvements. The anti-replay oracles this uses are trusted to not replay, but since they only deal with hashes they learn nothing about the transactions (or even that they're being used for a currency-like use—it might just be timestamping for all the oracle can tell). Such an oracle could be on trusted hardware, fidelity bonded, secured by a bounty txout that you can redeem if and only if you can publish a proof showing a replay, etc.
I think this is a better idea than the "trusted-computing bank" proposed by retep, because the oracle won't directly hold bitcoins, and it is also much more anonymous. I'm quite interested to build one, just for fun and for experiment. However, I have the following practical issues: 1. Do I need to buy very expensive TPM hardware to run this? As I know current Intel CPUs have trusted computing support. Could that be used for such purpose 2. It seems I have to hold an ever-growing list of hashes to avoid replay. That won't scale in long-term. Is there any solution? One way I could think of is to revoke signing key regularly and drop the related hash table. |
|
|
|
I'm totally cool with stuffing the data in alternate places once we have our own client. I see using unspendable transactions as a "crutch" so that the protocol works until we get to that point. For instance, right now none of the existing bitcoin clients has functionality that will let an average user hide data in OP_CHECKMULTISIG.
It is inevitable that in the future, bit coin does prevent the permanent storage of arbitrary data in the blockchain. If you rely on such features now, there could be colossal consequences later. #bitcoin wont care about you or your bitcoin-bloat. BE WARE, YOU HAVE BEEN WARNED. MasterCoin hopes to be symbiotic with bitcoin, not parasitic, and we plan to morph and change to whatever degree is needed as bitcoin morphs and changes. If our old data gets pruned out of the block-chain used by most bitcoin clients, our clients will have to be modified to keep different parts of the block chain, and use different pruning techniques. Nothing I can foresee leaves MasterCoin completely stranded or unusable. I won't be surprised. Parasites always morph and change as the host evolves. |
|
|
|
WHAT BANKS WORK WITH VENMO?
Your Venmo account works with all the major banks in the United States.
WHAT COUNTRIES CAN I USE VENMO IN?
Venmo can only be used in the U.S.
Well that eliminates what, 96% of the world from using it? It looks no better than Paypal - just with a nicer, social interface. LOL Some people believe USSA = the world [/thread] |
|
|
|
|
You can use the BTC mined with ASIC to pay other people doing vanitygen for you
|
|
|
|
The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).
There are many easier ways for a 51% attacker to violate the contract without major coding effort: - 1. collect fee according to bitcoin-days-destroyed, effectively turning Bitcoin to Friecoin.
- 2. request AML registration for every addresses, so bitcoin becomes the most traceable currency on the planet
- 3. turn it to SolidCoin by rejecting all blocks that are not signed by a central server
- 4. blacklist tainted addresses and transactions
- 5. collect miner tax: the 49% miners have to pay part of the reward to the attacker
1, 3, 5 are already happening in some altcoins. |
|
|
|
It wouldn't be possible to send an old client fake transactions, since they will still track the block chain. All blocks will just be empty.
This is probably the strongest argument for doing a softfork instead of hardfork. Having said that, if people wanted to continue, they could just blacklist the now empty blocks.
Yes. In any fork, soft or hard, people always have the option to follow the original one. |
|
|
|
Anyway, let me add my thoughts to this. First off, in the main-chain to aux-chain transaction, you could use that script with P2SH to make these transactions fully transparent, backward compatible, and standard all the way back to 0.6.0. The script for these transactions would only need to be revealed once the transaction is spent in the aux-chain. An interesting benefit of doing it this way is that it allows transactions to be sent to aux-addresses even in blocks that contain no aux-block. These transactions also don't need to be recorded in the aux-coinbase, since each client can independently convert the transaction to an aux-transaction once they have the script.
Secondly, on the return trip from the aux-chain to the main-chain, the transactions being sent should be sent to fees and picked up in the coinbase and sent to the designated scripts, that way they get locked for 100 blocks for all clients. This is important because a reorg would otherwise result in a different transaction hash for the aux-to-main transaction on the main chain side, breaking any transaction that may have depended on that transaction, even if that wasn't intended.
Interesting idea. So an aux-coinbase is needed only for collecting aux-fee and it's more block space efficient. A drawback is the need to store all genesis aux-transactions as they are required to redeem the locked fund in the main chain (though the people who want to redeem may supply such info to miners) There are different approaches to push the new protocol. 1. The one in OP is (I believe) the gentlest way. It allows people move between old and new protocol, and guarantee full fungibility of old and new coins. If there is any value difference between old and new coins, arbitrageurs will close the gap. The problem is that would make the protocol more complicated. After the majority of people have moved to aux block, we may stop processing any traditional transaction in the main chain*, and stop allowing people to redeem main-coin with aux-coin. All these could be done with further soft-forks. However, we can never completely obsolete the main block because some main-UTXO (e.g. lost coins) will always exist. (* with the P2SH suggested above, one needs to spend the coin at the aux-block immediately to show that's not a traditional P2SH transaction.) 2. The other solution is to create a no-return system from the beginning, as gmaxwell suggested at https://bitcointalk.org/index.php?topic=283746.msg3037821#msg3037821 . Actually I think this is not a good idea because no one would want to be the guinea pig to send bitcoins to the aux block, with the risk of being locked in limbo. As a result, the value of aux-coin will be lower than main-coin, and further reinforce the reluctance to the transition. Even if the aux system is superior than the old one, it still won't be adopted. Therefore, any no-return system must be accompanied by banning any traditional transaction, as suggested above. 3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly. 4. We can combine approaches 1 and 3. Approach 1 is implement at first. The code, however, further indicates that the approach 3 will be adopted if >95% miners agree and >70% of UTXO are in the aux-chain. |
|
|
|
|
The best way is to send your whole balance to your new wallet
|
|
|
|
This reminds us that a 51% attacker could do a lot more than we usually think.
Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks. Attackers can reject any tx that is not following their rules. Other people could either follow, or hardfork |
|
|
|
|
Show Posts
