|
ATM, The UTXO set is 239,681,979 bytes out of 10,618,084,349 bytes, or 2.26% of the total blockchain
I have proposed it for many times: set a hard limit for the growth of UTXO (e.g. 1% of max block size, i.e. 10kB) per block, so the UTXO set will grow at most 525MB per year. This will encourage people to merge dust outputs, and punish any UTXO-bloating activities. At the same time, we could make OP_RETURN as standard output and not count it as UTXO growth.
|
|
|
|
Did you see what I was suggesting with respect to making spends provisional? E.g. you provide a header fragment to redeem, the txout moves to a new txout which is released to you after some span of time— or, alternatively, can be updated by someone else providing a longer conflicting chain of headers. The idea is that rather than you going out to seek the chain's information, some interested party (e.g. real owner of the coin) brings it to the blockchain.
Sounds reasonable. Coupling with PoW requirement makes it economically prohibitive to steal or DoS One possibility, borrowing from my whimsical CoinCovenants thread, would be to have the CoinWitness program designed to enforce that a timeout recovery pays the output to another a scriptpubkey which can either be redeemed by you after a second timeout OR can be redeemed by another timeout recovery which presents a _longer_ transcript. In this case a timeout unwind would be very likely to go to the person with the longest transcript and that might mostly remove the attack incentive the timeout creates. E.g. if you try to cheat and present a truncated transcript in order to steal some coins, before the coins are finally released to you someone with a longer transcript comes along and takes them back. This will allow any previous owners to DoS the latest owner by forcing him to redeem the coin on the blockchain. |
|
|
|
SPV requires a user to monitor the network, look for the longest PoW chain, and verify whether a transaction is adequately buried in the longest chain.
Fair enough. There is ambiguity in what SPV means— e.g. go see what electrum, which does not monitor the network, calls itself or the BitcoinJ clients which get their peers exclusively via DNS. Can you suggest a better name for "SPV with high risk of network isolation"?  It would probably be a good name to have. SPV, defined by Satoshi, "needs to keep a copy of the block headers of the longest proof-of-work chain". There is no ambiguity on this point. "network isolation" is exactly the term I want to use. I just find a possible solution to mitigate this problem. For a low value transaction (say 0.1BTC), one may believe it is economically prohibitive to do a certain amount of PoW (say 4000PHash, which should give 250BTC reward if one mines honestly) just to steal it. So the SCIP script will require the tx to be buried by at least 4000PHash of work. Thought? |
|
|
|
You're speaking specifically about the blockchain consensus example, which I specifically noted only has SPV security: As I pointed out earlier, it is worse than SPV security. SPV requires a user to monitor the network, look for the longest PoW chain, and verify whether a transaction is adequately buried in the longest chain. In your blockchain based SCIP example, however, bitcoin miners will not monitor the alt-chain and won't know its current height. Bitcoin miners will accept the SCIP proof as long as the transaction is adequately buried, but this is not necessarily in the longest chain. Therefore it is (much) worse than SPV model. On the other hand, if all bitcoin nodes are required to validate the alt-chain, it is basically equivalent to my aux-block proposal: https://bitcointalk.org/index.php?topic=283746.0 |
|
|
|
The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.
The complicated part should be transparent to users. Eventually, all tx will happen in the aux block, leaving only a dummy coinbase tx in the main block (which works as extended block header). The risk of hardfork is too high and I believe it should be used only in absolutely necessary cases like: - Bug fix like BIP50
- Timestamp overflow in year 2106
- SHA256 is completely compromised
I believe these are the ONLY scenarios that a hardfork is unavoidable. Please point out other scenario if anyone finds one. |
|
|
|
So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.
If an attacker did that, then he would fork the chain. "Soft-fork" is actually relative. It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules. This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power. A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it. If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition) |
|
|
|
|
Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many aux coins as they want, steal ancient aux UTXO, etc. Minority users need to hardfork if they don't like these rules.
|
|
|
|
Once a transaction is in the aux block all of its children must forevermore be in the aux block.
This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.
The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.
With this approach, we could change pretty much everything in the protocol with soft-fork. Just some examples: - The way to calculate tx hash
- Coin divisibility
- New fields in block header and transaction
- Native color coin support
- Shorten block time interval
- Ultimately, we could trim the original Satoshi protocol to absolutely minimal (probably except the few involving block headers like double SHA256 PoW and Merkle Tree), and implement a completely new set of rules
For the fungibility problem, a very aggressive solution is to create a genesis-aux-block with all UTXO in the main chain. New miners will collect their reward in the aux-chain only, and they will reject any main chain tx except the dummy coinbase tx with zero value. So all old nodes are broken immediately, but it's still a softfork because the PoW is still valid for them. I call this the ultimate-51%-attack. |
|
|
|
|
With aux-block, some other hardforks could also become softforks. For example, the calculation of tx hash in aux-block may exclude scriptSig, so transactions are identified purely by their inputs and outputs.
|
|
|
|
What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.
And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code) Just a minor note: just like v2 block, the aux-coinbase must include the height of the corresponding main block to avoid crash of tx hash. |
|
|
|
If there is no aux transaction, there will be no aux-block, even from a upgraded miner. So basically aux-blocks do not form a chain. They are the extension of the main blocks, indicated by the Aux-Merkle-Root in the main-coinbase. For backward compatibility, aux-block will not be sent to old nodes. A new command like getauxblock will be used among new nodes. This means that there is always a one to one mapping of aux-block to main block?
What happens if there is a block with no aux-block (say mined by an old miner)? I assume it is just like a main chain block, but with no transactions?
Miners would refuse to build on new blocks if there is no aux-block? Would you foresee a new message type?
In fact, what happens if you send extra data in a "block" message? I assume it is basically ignored?
The extended block, could be of the form
...
...
varInt: n = number of transactions in main block
tx[n]: transactions
varInt: m = number of extra transactions
aux-tx[m]
I think the current client basically ignores extra fields.
This would allow blocks of 32MB. You need a way to split blocks over multiple messages to go above that,
|
|
|
|
|
I just realize that the 1MB block size limit could be increased with a softfork. I call it auxiliary block:
1. An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.
2. OP_NOP1 is redefined as OP_AUX
3. Initially, auxiliary blocks are empty, until someone sends X bitcoin to a scriptPubKey of this format: <serialized script x> OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to <deserialized script x>. The Merkle Root of the auxiliary block will be included in the coinbase of the main block. All upgraded nodes will check whether the bitcoins are correctly transferred from the main chain to the aux chain
4. People can transfer aux chain bitcoins like in the main chain. Miners can also collect fee in the aux chain using the same mechanism as the main chain. The only difference is there is no generation bonus in aux chain. New aux coins are generated if and only if someone send bitcoins to <serialized script> OP_AUX in the main chain
5. When someone want to transfer Y aux coins back to the main chain, he will send Y aux coins to a scriptPubKey of this format: <serialized script y> OP_AUX OP_RETURN. Seeing this, the miner will randomly choose some OP_AUX UTXO in the main chain, with value exactly equals to Y bitcoins, and pass them to <deserialized script y> in the main chain.
Backward compatibility:
1. Since old nodes will not see the aux block, the aux block could be indefinitely big
2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.
3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.
4. Old nodes can still mine. As long as they are not trying to include or redeem OP_AUX transactions, their blocks are still valid.
(More extremely, we may disallow people transferring aux coin back to the main chain by requesting them to send bitcoin to <serialized script x> OP_AUX OP_RETURN on the main chain. This will provide better backward compatibility since such outputs are not redeemable in both new and old nodes, and old miners would see these as non-standard and won't mine them)
|
|
|
|
|
Don't need to be so complicated: public-key cryptography is exactly what you need.......
|
|
|
|
Have any actually ended up in the block chain?
Never: you can search d21633ba23f70118185227be58a63527675641ad37967e2aa461559f577aec43 with google However, I wonder if this is a valid transaction (if someone put it in a block, is the block still valid?) |
|
|
|
Blockchain based
Alice has a bitcoin which is represented by a colored coin in some other specific blockchain, perhaps a geographic-specific blockchain.
Alice passes it to Bob by transacting in the normal way.
Bob can form the verifiable transcript by grabbing every transaction along the colored coin's path along with the SPV fragments connecting them to the chain and some additional blockchain headers to show the transactions are adequately buried. What prevent Alice from forking the alt-chain and double spend after she sent the coin to Bob? When talking about SPV, one needs to know the height of the longest chain. Since the SCIP program won't be able to learn this, the attacker doesn't even need to outpace the honest chain. |
|
|
|
|
It is the first time since the big crash we hit overbought zone in daily RSI, in all major markets (gox, stamp, e and china)
|
|
|
|
Such an oracle could be .... secured by a bounty txout that you can redeem if and only if you can publish a proof showing a replay, etc.
I don't think this works. Before the oracle operator doing evil things, he could generate a replay proof and redeem bounty for himself |
|
|
|
|
"日后我打算操作时再把Private Key复制进文件夹": 這只比熱錢包好一點點, 因為黑客可以在這時候取得private key
如果你想要冷錢包, 又不想佔用資源, 最好是用Electrum
|
|
|
|
|
Is it possible to run the SCIP calculation on GPU? Would it be more efficient than CPU? We may even have SCIP-ASIC in the future.
However, I think the blockchain-based system does not really imprlove scalability a lot, because it just shifts the burden to the alt-chain. To make it more scalable, the alt-chain must be less secure than bitcoin, e.g. using smaller key size and hash length (therefore smaller signature), limited coin life (ancient UTXOs are pruned). This might be good enough for small amount transactions.
For the oracle-based system, there is a risk of shutdown of the oracle, which will lock all BTC in limbo. Although we may use M-of-N oracles but the risk is still here. Instead of signing {HC,SHB}, I wonder if the oracle may sign {HC,SHB,SHBx}, where SHBx specifies a time-locked transaction sending the bitcoin to Bob's address ("the emergency transaction", "ET"). When passing the off-blockchain bitcoin to Bob, Alice has to provide the details of all ETs in the chain, and Bob will check whether his ET has an earlier locktime than all the previous ETs. Bob has to spend or redeem the off-chain coin before the locktime of Alice's ET, or Alice will be able to redeem the coin on the blockchain. If this is possible, we could significantly reduce the risk of cheating by requiring a bigger N in an M-of-N oracles system (or simply use M-of-M).
|
|
|
|
|
Show Posts
