The reason for mapRelay (i.e., storing relayed data in wire format, rather than in parsed form), was I believe historically because Satoshi wanted to be able to extend the different data structures later in newer versions, and have old code relay them. I'm sure he didn't consider DoS attacks when designing this.
FWIW I took a quick look at v0.1 - it has the comment "Save original serialized message so newer versions are preserved" in RelayMessage() so I'm sure your theory is correct. |
|
|
|
Wait.....there is a big loophole. If subset generation and sig checking are decoupled, an attacker can use a signature for another transaction to redeem any outputs of the same script, because he can bypass those OP_PUSHOUTPUTWITHVALUE codes and feed the CHECKSIG with the subset hash of the previous transaction directly. I think that was the reason why Satoshi made OP_CHECKSIG doing everything.
How would that happen? All the processing would still happen in the scriptPubKey, out of the control of the attacker. |
|
|
|
What happened to OP_RETURN? In bitcoin wiki it just says "Marks transaction as invalid." How could it satisfy any output? Has the definition changed?
wiki wording does not precisely match actual function. Heh. OP_RETURN used to cause script processing to exit immediately, leaving the stack untouched. If the top stack item evaluated true, the script would succeed, false, the script would fail. This was changed in a75560d828464c3f1138f52cf247e956fc8f937d - notice how Satoshi didn't mention the changes at all. That's pretty much the last time the scripting code has seen any major changes FWIW. Also note how at the same time Satoshi also added some other hard-fork changes, like adding a 20KB size limit on scripts. (later reduced to 10KB in 73aa262647ff9948eaf95e83236ec323347e95d0 along with more hard-fork changes, this time with a commit message mentioning security) Here's another fun one: OP_DOUBLEBYTE_BEGIN. Never implemented, but looks like the idea was to add some two byte opcodes eventually. Also OP_NOTEQUAL, an opcode that was disabled in v0.1 |
|
|
|
It seems that Satoshi code was not designed to protect you from DoS, but it’s also true that the core developers have tried to add some DoS preventions since the Satoshi times. In any case, it’s only a minor vulnerability or flaw. What worries me is not that a bug was found, nor that a bug in the patch was found, but that the github commit of the patch does not show a history of a discussion regarding the patch correctness, nor it is recorded if the code was audited and by whom. This lack of standardized protocol for the treatment of sensitive patches should be corrected, and I offer myself to review security critical code, whenever it is needed, and whenever I can. FWIW the discussion regarding the patch happened in private email CC'd to all core developers and the bitcoinj developers; nearly everyone CC'd participated in the discussion, and did so in only a few hours. This patch was unusual because it was written during an active attack on mainnet, and doubly unusual because you only need a small number of patched nodes to stop the attack against the network as a whole. (individual nodes are still vulnerable) It's fine to think about protocols for vetting security-related patches, but it'll be awhile before the Bitcoin project has the resources to hire the multiple full-time staff with overlapping schedules we need to really use those protocols effectively. Unfortunately it's an response time vs. risk tradeoff without one-size-fits-all answers. Frankly the best I can say is donate to the Bitcoin foundation so they can hire more developers. |
|
|
|
|
It looks like even having that cache enables and/or makes worse other types of attacks, so right now I'm thinking it probably should be removed completely, but I want to think more about the issue. (the extra memory usage is probably more expensive than re-serializing on demand)
Also yet another example of why zero-conf is dangerous.
|
|
|
|
|
I'd suggest you think about how you could separate CHECKSIG into three steps: generate transaction subset, hash, check pubkey signature. If you can figure out a rational way to split up the "generate tx subset" part, all the better.
We're much more likely to be able to successfully test a new CHECKSIG implementation if it's split into modular parts; we can always have opcode aliases so that really common sequences are compressed into a single alias even if the backend runs a whole bunch of opcodes.
|
|
|
|
The merchant doesn't need to see the full tx1 before he signs tx2. He just needs the hash of tx1 and the corresponding output index. If the merchant uses a brand new private key, he can blindly sign the tx2:
1. Merchant sends a new public key (Pu-M) to user
2. User creates a transaction (tx1) to send bitcoin to 2-of-2 multisig of Pu-M and Public key of user (Pu-U). DO NOT BROADCAST
3. User creates a timelock transaction (tx2) to send the multisig output of tx1 back to himself; sign it; pass it to merchant
4. Merchant signs tx2 WITHOUT KNOWING tx1
5. User sees the fully signed tx2. Broadcast tx1
6. Merchant acknowledge the tx1 after several confirmations
Yup, you're absolutely right, which means jspilman's micropayment system is completely secure for both parties once tx1 confirms, and until then simply has zero-conf security. It's also still compatible with replace-by-fee scorched-earth: if the user double-spends the unconfirmed tx1 paying into the multisig output, and has signed a non-timelocked tx2, sign tx2 spending the amount that doesn't get refunded back to the user 100% to fees and they'll still pay for whatever they owe. Exactly the same as scorched-earth for a non-micropayment-channel transaction. Heh, the confusion we've all had in examining this stuff makes me think when it comes to OP_CODESEPARATOR we should always consider the possibility that Satoshi simply made a mistake in the design. But anyway, I always love the idea of OP_PUSHBLOCKHEIGHT. This has been discussed many times here. It simplifies the process a lot and could be wrapped as P2SH. User can keep sending bitcoin to the same P2SH address without those timelock txs. I am just not sure how it could be done as a soft-fork. I think a soft-fork new OP code could only be "nothing or fail". Unless you wrap it as a serialized script and run it with a re-defined OP_NOP, and make it looks like send-to-anyone to old clients, i.e. <serialized script> OP_RUN OP_DROP OP_TRUE Basically the best way to do it is to make script-v2 based on merklized abstract syntax trees and push it all into one opcode:
<MAST-top-level-hash> OP_NOP1/OP_MAST_EVAL
For pre-soft-fork nodes the OP_NOP1 does nothing, and the top-level-hash will make the script evaluate as true. (the hash would never be == 0 for a valid script) The scriptSig is then the fragments of the abstract syntax tree of the part of the script that is actually executed. For instance, lets say all the script is executed:
scriptPubKey: <hash> OP_MAST_EVAL
scriptSig: <sig> (<pubkey> OP_CHECKSIG)
Basically this looks just like P2SH. But lets suppose a more complex scriptPubKey:
IF <pubkey1> OP_CHECKSIG
ELSE <pubkey2> OP_CHECKSIG
ENDIF
You spend it with either:
scriptSig: <sig1> 1
scriptSig: <sig2> 0
But with MAST you only have to reveal the branch actually being executed, so your scriptSig now looks like this:
<sig1> 1
(IF <pubkey1> OP_CHECKSIG
ELSE Hash(<pubkey2> OP_CHECKSIG)
ENDIF)
For two branches, it's not a big savings, but I could have embedded a hundred possible pubkeys into that script with nested if statements, yet to spend the script I only have to provide the data required to execute one short path. I also don't have to reveal any parts of the script that weren't executed if I don't want to. edit: Credit goes to Russell O’Connor and Pieter Wuille for this idea. |
|
|
|
I was browsing the forums while ignoring a boring presentation. I didn't read the whole exchange in detail, just enough to confirm my guess at the function of the script presented.
As you may have noticed from my post, I'm not as willing to handwave over adding state to transactions. I follow the argument about checking history as well as confirmations. I think that it might be too complicated to make reasonably accurate estimates of security once branching is added.
When you say "state" what exactly are you referring too? |
|
|
|
How can the counter-party vanishing affect this? You get the refund (Tx2) signed by the payee before you (payor) sign the funding transaction (Tx1). That essentially makes the whole operation atomic: either all parties get their money into an escrow that automatically returns to the payor if one of the parties disappears... or nothing happens.
It's not possible to sign tx2 until tx1 is fully signed; tx2 refers to tx1 by it's hash, which includes the signatures. (the original micropayments channel writeup on the wiki had this mistake too) |
|
|
|
This example says that you need to satisfy a multisig with two keys, until the transaction reaches a certain depth, when it can be redeemed by one script. The idea is that it removes the risk of the counterparty disappearing by giving the first guy the ability to reclaim his money in the future.
To be clear the protocol implemented now is that a time-locked refund tx is created when tx1 is created that returns the money in the future, but ultimately there will always be a short time window where the counter-party can vanish leaving the funds locked. Jeremy Spilman's solution was to have the counter-party also include some funds, so that their funds would be locked as well so the counter-party has strong incentives to not allow this to happen; I'm not sure what bitcoinj has implemented. |
|
|
|
Sorry I don't understand <height + n> OP_DEPTH OP_LESSTHAN
IF 2 PK1 PK2 CHECKMULTISIG
ELSE PK1 CHECKSIG
ENDIF OP_DEPTH "puts the number of stack items onto the stack." What's its function here? Good catch. We've been using the term "OP_DEPTH" to talk about an idea to do a soft-fork to allow a transaction to query the block height of the block including the transaction in some way. I forgot there already is an OP_DEPTH opcode, which makes it a horrible name. I'll call these hypothetical opcodes OP_BLOCKHEIGHT, OP_TXOUTHEIGHT and OP_TXOUTDEPTH in the future to be clear. Sorry about that. |
|
|
|
|
Doh, I totally missed that somehow...
|
|
|
|
Is there a way to tell how many keys there are left in the keypool?
AFAIK no. That'd be a good thing to add to the getinfo RPC call, and it can be set to MAXINT when type 2 wallets are implemented. |
|
|
|
Peter, I wish you would stop talking as if you are The Decider when it comes to Bitcoin. You routinely make pronouncements about what "will" or "will not" happen as if it's done and dusted when in reality these are just your personal opinions.
Standard disclaimer: Bitcoin is democratic and doesn't have deciders. I'll get around to posting the summary of the discussion myself, luke-jr and gmaxwell had about nLockTime-by-time on -wizards soon. |
|
|
|
...we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too
Can you elaborate on this? Or point me to where the technicals are described? I was not aware of this development. Jeremy Spilman's solved it: http://permalink.gmane.org/gmane.comp.bitcoin.devel/2037 Bi-directional channels are easily done by setting up two channels in opposite directions. Also see my note about using OP_DEPTH that I just posted to the -dev email list. |
|
|
|
We've got a rabid one here.
Sorry about that - piotr_n is a bot I wrote to get all the good material out of gmaxwell's brain to plagiarize for my upcoming book on crypto-coin theory, "Proof of Work Consensus" (yes I see the irony of the title) I'll see if I can tweak the settings a bit. |
|
|
|
Yes, exactly. Multisig isn't a feature that really makes sense to expose directly. You build apps on top of it.
Is locktime actually supported at the moment? I know replacement isn't. Yes, works just fine, although we're probably going to need a soft-fork to fix some bad incentives made possible by time-based nLockTime. (by-height is fine) The first production code to use it will likely be for announce-commit sacrifices for jgarzik's identity protocol stuff. Satoshi's implementation of replacement is one of the more dubious bits of design put in Bitcoin. It'll never be enabled the way Satoshi intended, and we've found that micropayment channels don't need sequence numbers anyway, and the non-sequence-based version is far more secure too. (no dependency on zero-conf) |
|
|
|
To the extent that a pooled miner is actively checking forums etc. to listen for claims that their pool is misbehaving, and switching pools in such an event, then I think they are contributing somewhat.
How is the miner checking forums if the internet doesn't work? On the other hand, if forums aren't blocked, bitcoin is sufficiently low traffic that you can stegonographically hide the blockchain data in what parts of the internet aren't being blocked and thus there isn't a problem. |
|
|
|
The last problem for a zerocoin implementation is the generation of an RSA modulus for which no one knows the factorization. This is hard, and deserves more analysis.
If someone finds out the factorization, what are the implications? All the anonymous transactions become public? No, but they can use the key to create fake zerocoins. (basically they can fake the proof that they added a zerocoin to the accumulator) |
|
|
|
|
Show Posts
