You're correct, TX maleability is only an issue if people use the TX hashes as Ids.
The problem with not using tx hashes as a transaction ID, is that tx hashes are exactly what the block chain itself uses as a tx ID when specifying what transaction's output to use as an input. If you don't know the transaction hash in advance, you can't make a transaction that spends its output in advance. And if you can't make transactions that spend outputs before the outputs they spend actually get into the block chain, then a lot of escrow and other protocols don't work. We need transaction ID's to be stable. Can we make the tx hash by exclusively hashing things that nobody outside the original transaction set can change? Yes, but that would need a hardfork, or a very complicated softfork. I proposed this last year: (1) The txid will be the hash of the tx with all scriptSig removed. (currently, txid is the hash of the tx, including all scriptSig) (2) The first level of merkle root will be hash of (txid-a|size-a|txid-b|size-b), where txid-a and size-a are the txid and size of tx-a respectively (currently, the first level of merkle root is (txid-a|txid-b)) With (1), no third party mutation of the txid is possible. Even when spending n-of-m multi-sig output, the txid is mutable only if n signers agree (currently, any 1 signers may mutate it) However, due to scriptSig malleability, there is an infinite number of ways to record the same tx. Therefore, we need to put the tx size in the formula of the merkle root. For a tx to be valid, it must be equal or smaller than the size indicated. This guarantees that blocks in different nodes will have an upper size limit. However, the actual content the txs could be different, as long as they are valid. |
|
|
|
I'm still not so sure tx malleability is a real issue. One can always check that the receiving address received payment from the sending address. And what else is really so important? In the recent proposal of payment channels (lighthouse) there is also talk that malleability could cause a problem. I haven't understood how that is the case yet. What am I missing?
You're correct, TX maleability is only an issue if people use the TX hashes as Ids. You're not correct, things are not that simple. Malleability has big impact on any anything depending on transaction hash of unconfirmed transactions, e.g: |
|
|
|
Depends on what you mean by refund protocol. As soon as your pattern makes multiple transactions-- e.g. the escrow makes change back to the escrow, things are broken again.
Then just make it be escrow -> customer -> escrow. Or to fix it permanently, we may have a hardfork (or a softfork in a creative way) to replace txid with normalized-txid. This will ensure that a safe subset of tx (SIGHASH_ALL and pay-to-key-hash/pay-to-pubkey) will be totally free of malleability. |
|
|
|
Pieter has a new proposal which makes major improvements: every softfork is signaled by a single bit, the when the bit crossed threshold it 'latches' and
becomes available for reuse again, and there is a deadline by which if it fails to latch its aborted and becomes available for use again.
But there are only 32 bits in the version. It will be exhausted very soon if it is used in this way, isn't it?
Keep in mind, that for refund protocols where the potential attacker is a signer of the transaction no "fix" in the form of signature encoding improvements is possible; their problem is not that transactions are malleable but that the malleability matters. BIP66 is about preventing (we hope) third party malleability.
By third party malleability do you mean the ability of mutating a tx without private key? I think this is the only type of malleability we may fix. Private key holder will always be able to mutate and double spend a tx before it is confirmed. I'm not sure if I misunderstand you. In the refund protocol, the potential attacker (i.e. the payee) does not need to sign the payment to the escrow address. It should work like this: 1. Merchant generates a new private key, and send the public key to the customer. 2. Customer creates a 2-of-2 P2SH address with his own public key and merchant's public key 3. Customer creates a tx, sending some bitcoin to the P2SH address from step 2, but not publishing the tx 4. Customer asks the merchant to sign a nlocktime refund tx with the outpoint from step 3. 5. Customer publishes the tx from step 3. 6. After the tx from step 3 is confirmed, customer shows the script to the merchant to prove that the bitcoin is under escrow. Customer may lose money if tx mutation happens between step 5 and 6. However, if we fixed all known third-party malleability, the customer is the only person having to ability to mutate it but he has absolutely no incentive to do it. |
|
|
|
we have BIP66 but there are still many forms of malleability to be fixed.
BIP66 is not about malleability, really; BIP62 is. But in the BIP66 description it says it "has the added benefit of reducing transaction malleability": every non-compliant signature can trivially be converted into a compliant one, so there is no loss of functionality by this requirement. This proposal has the added benefit of reducing transaction malleability (see BIP 62). And if a non-compliant signature can trivially be converted into a compliant one (I assume private key is not needed for such conversion?), why isn't it a source of malleability? What you're describing has previously been described as "Block discouragement"; here I think it has all the software complexity of a normal soft-fork plus the additional complexity of the discouragement mechanism.
Most block discouragement rules should eventually become soft-fork rules. So the code should be pretty much reusable. The code for discouragement mechanism is also reusable in the future. I do not see how this helps much; the reversibility is a selling point, but at a far from zero cost. We'll be moving on 62 once 66 is actually deployed (one flaw in the the legacy softfork deployment mechanism is that only one change can be in flight at a time)
As mining becomes more professional and competitive, miners will try everything to reduce the stale rate. It's not zero cost but most work done are reusable. And the selling point is low risk, not low cost. Can we deploy 2 (or more) soft-fork concurrently like this: block version 3 is BIP62 only; block version 4 is BIP66 only; block version 5 is both BIP62 and 66? |
|
|
|
tx malleability could cause big trouble. I think all devs agree that we have to fix it some point in the future. However, due to the risk involving soft-fork, this could only be done very slowly. Now we have BIP66 but there are still many forms of malleability to be fixed. I propose to have to a technique called "semi-soft-fork" as a remedy before a real soft-fork is done. Currently, transactions are divided into standard and non-standard. I propose to divide it into 3 types: - Standard tx (ST): a valid tx with a strict set of scriptSig and scriptPubKey, with all known malleability issues fixed
- Type 1 non-standard tx (NST1): any mutated standard tx, otherwise valid
- Type 2 non-standard tx (NST2): any other valid tx not in the previous categories
A block with only ST is a standard block (SB). A block with at least 1 NST1 non-standard tx is a Type 1 non-standard block (NSB1). A block with no NST1 but with at least 1 NST2 is a Type 2 non-standard block (NSB2). SB, NSB1 and NSB2 are all valid blocks, just with different level of standardness Miners joining this semi-soft-fork will still try to mine the longest chain, no matter the blocks in it are SB, NSB1, or NSB2. However, if there are forks with same length, the miner will always switch to the fork with least number of NSB1. If there are enough miners joining this semi-soft-fork, it will provide incentive for the rest of miners to avoid NST1 and NSB1. Therefore, the risk of tx malleability is reduced. And since this is not a consensus rule change, it is easily reversible if anything goes wrong. It will also allow us to test the anti-malleability code before we migrate to a real soft-fork. |
|
|
|
But isn't that precisely what this proposal is intended to deal with?
so he would have to mutate every possible transaction in order to get a mutant mined instead. This would be much harder/more costly (at least if P2SH were widely used).
This proposal assume that Bob would not take a spray-and-pray strategy. As someone is now randomly mutating transactions on the network, the proposal won't work My question a year ago has not been answered. As someone may attack the network by randomly mutating txs, just like what we had last year, no txid should be considered as final before it is written in the blockchain. |
|
|
|
But this 'no chargeback' feature will be hard to accept for masses of people in the future.
Agree. The "no chargeback" feature might scare some/most people away from adopting bitcoin. They know bitcoin is a digital currency, and they know that transactions using Visa/Mastercard/PayPal require digital processing, so they'll automatically equate bitcoin to Visa/Mastercard/PayPal including the standard security feautures like chargebacks. In that way, it makes perfect sense for people to expect that bitcoin should have chargeback services. What you are asking for is not "chargeback". It's a trusted arbitrator. VISA/MC/PP are just trusted arbitrators. There is nothing to prohibit people to use bitcoin through a trusted arbitrator. |
|
|
|
everyone here is escaping from paypal chargeback and you want to add it to bitcoin? no way, i want bitcoin to remain irreversible
maybe it can be added via sidechan for merchants only, if they really need it for adoption, in the future
If you are talking about PP chargeback then you don't need any protocol change. We already have bitpay doing the same thing with bitcoin yeah but i think the op is talking about a system that deal with bitcoin only, between privates for example(goods for btc ecc...) I explained why this is a stupid idea: https://bitcointalk.org/index.php?topic=1032946.msg11146097#msg11146097It is stupid not because we want to escape from chargeback. It's because it won't offer any benefit to both customers and merchants. |
|
|
|
everyone here is escaping from paypal chargeback and you want to add it to bitcoin? no way, i want bitcoin to remain irreversible
maybe it can be added via sidechan for merchants only, if they really need it for adoption, in the future
If you are talking about PP chargeback then you don't need any protocol change. We already have bitpay doing the same thing with bitcoin |
|
|
|
I know that it is possible to modify bitcoin and add chargeback functionality
How? That is indeed an excellent question. AFAIK, once a transaction is registered in the blockchain that is that. So I will repeat what jl2012 asked.... HOW?Technically it is not impossible to include chargeback in the protocol. However, it's just a very stupid idea because it will never achieve what it intends to achieve. If the payer is able to reverse a transaction without the permission of the payee or any trusted third party, no merchant will deliver goods as a customer may reverse the transaction after delivery. If the payer is able to reverse a transaction within certain time period, say 10 days, no merchant will deliver goods within 10 days for the same reason. If the customer tries to reverse the transaction, the trade is simply cancelled. If the customer does not try to reverse the transaction, he will lose the chargeback protection and may or may not be scammed. So just stop arguing to have chargeback in bitcoin protocol. |
|
|
|
I know that it is possible to modify bitcoin and add chargeback functionality
How? |
|
|
|
This is by design. If you want full tx traceability you'll have to use supernode.
Isn't it better just to mask the inputs table, rather than showing wrong data? |
|
|
|
I always feel uneasy to connect a device with private key directly to an untrusted online computer I hope something like a audio modem could be implemented but seems it's too slow to be practically used? https://bitcointalk.org/index.php?topic=135423.0 |
|
|
|
Am not sure how Armory stands with regards to using audio (I do recall them offering a bounty for that) but unless that is included in the current product then it is not the "gold standard" as it relies upon USB which could be hacked. The CIYAM Safe ( https://susestudio.com/a/kp8B3G/ciyam-safe) does not rely upon USB for txs but uses QR codes which are safer (i.e. 100% air-gapped). Perhaps terms like "gold standard" should simply be avoided (they sound like marketing sound bytes to me anyway). ok I corrected it. I agree that the use of USB is not ideal. But Armory is still one of the best cold wallets |
|
|
|
You don't understand probably because you read some poorly written articles. If you want cold storage forget blockchain.info wallet. Armory is the gold standard a good implementation of cold storage. Please read this before you ask further questions: https://bitcoinarmory.com/cold-storage/ |
|
|
|
脑钱包一直以来都是被认为不安全的。 冷钱包维护成本又太高，思来想去还是觉得在iPad上注册和使用Blockchain钱包安全！
blockchain.info 錢包的設計本來就很不安全, bitcoin.org已將之除名 |
|
|
|
Transactions made with current clients have outputs like OP_DUP OP_HASH160 <pubkey hash> OP_EQUALVERIFY OP_CHECKSIG where transactions made in the early blocks of the block chain have outputs like <uncompressed-public-key> OP_CHECKSIG And under the hood, these are treated the same way. This is simply pushed onto the script interpreter stack when it's spent and then the spend script operates on the stack. And the same spend script - namely <signature> <pubkey> works to spend either kind of output. Is there any problem with a transaction containing an old-style txOut if it were made today? Would it be considered non-standard and not relayed? "<uncompressed-public-key> OP_CHECKSIG" is spent by "<signature>", not "<signature> <pubkey>" anyway, it's still standard. |
|
|
|
|
Show Posts
