Re: [Bitcoin-development] network disruption as a service and proof of local storage
On Mar 27, 2015, at 8:16 AM, Matt Whitlock b...@mattwhitlock.name wrote: Isn't the goal of this exercise to ensure more full nodes on the network? Basically we're talking about a form of Sybil defense and better quantifying true blockchain resiliency by proof of storage. In this case the goal is to see if we can prove the number of distinct digital copies of the blockchain. This is actually a tricky problem because it will (always?) devolve to inferences from response timing, and we are running over a heterogenous network with heterogeneous machines. It would be extremely impressive to achieve a reliable mechanism for discerning a local copy exists under these constraints, particularly without false positives and false negatives, and without imposing very substantial one-time encoding costs, e.g. on par with doubling the verification cost. I think while its a difficult cost-benefit analysis, even code complexity aside, it's interesting to discuss all the same! Simply having many unique IP addresses possibly accessing the same unique copy provides a different (if any) benefit. E.g. Tor uses IPs as a cost factor, but (until recently?) didn't even factor in things like them all being the same Class C. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] network disruption as a service and proof of local storage
On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner sergioler...@certimix.com wrote: I proposed a (what I think) is better protocol for Proof of Storage that I call Proof of Local storage here https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/ Thanks so much for publishing this. It could be useful in any application to try to prove a keyed copy of some data. If I understand correctly, transforming raw blocks to keyed blocks takes 512x longer than transforming keyed blocks back to raw. The key is public, like the IP, or some other value which perhaps changes less frequently. The verifier keeps blocks in the keyed format, and can decrypt quickly to provide raw data, or use the keyed data for hashing to try to demonstrate they have a pre-keyed copy. Two protocols can be performed to prove local possession: 1. (prover and verifier pay a small cost) The verifier sends a seed to derive some n random indexes, and the prover must respond with the hash of the decrypted blocks within a certain time bound. Suppose that decryption of n blocks take 100 msec (+-100 msec of network jitter). Then an attacker must have a computer 50 faster to be able to consistently cheat. The last 50 blocks should not be part of the list to allow nodes to catch-up and encrypt the blocks in background. Can you clarify, the prover is hashing random blocks of *decrypted*, as-in raw, blockchain data? What does this prove other than, perhaps, fast random IO of the blockchain? (which is useful in its own right, e.g. as a way to ensure only full-node IO-bound mining if baked into the PoW) How is the verifier validating the response without possession of the full blockchain? 2. (prover pay a high cost, verified pays negligible cost). The verifier chooses a seed n, and then pre-computes the encrypted blocks derived from the seed using the prover's IP. Then the verifier sends the seed, and the prover must respond with the hash of the encrypted blocks within a certain time bound. The proved does not require to do any PH decryption, just take the encrypted blocks for indexes derived from the seed, hash them and send the hash back to the verifier. The verifier validates the time bound and the hash. The challenger requests a hash-sum of a random sequence of indices of the keyed data, based on a challenge seed. So in a few bytes round-trip we can see how fast the computation is completed. If the data is already keyed, the hash of 1,000 random 1024-bit blocks should come back much faster than if the data needs to be keyed on-the-fly. To verify the response, the challenger would have to use the peer's identity key and perform the slower transforms on those same 1,000 blocks and see that the result matches, so cost to challenger is higher than prover, assuming they actually do the computation. Which brings up a good tweak, a full-node challenger could have to do the computation first, then also include something like HMAC(identityKey, expectedResult). The prover could then know if the challenger was honest before returning a result, and blacklist them if not. Both protocols can me made available by the client, under different states. For instance, new nodes are only allowed to request protocol 2 (and so they get an initial assurance their are connecting to full-nodes). After a first-time mutual authentication, they are allowed to periodically perform protocol 1. Also new nodes may be allowed to perform protocol 1 with a small index set, and increase the index set over time, to get higher confidence. I guess a new-node could see if different servers all returned the same challenge response, but they would have no way to know if the challenge response was technically correct, or sybil. I also wonder about the effect of spinning disk versus SSD. Seek time for 1,000 random reads is either nearly zero or dominating depending on the two modes. I wonder if a sequential read from a random index is a possible trade-off,; it doesn't prove possession of the whole chain nearly as well, but at least iowait converges significantly. Then again, that presupposes a specific ordering on disk which might not exist. In X years it will all be solid-state, so eventually it's moot. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin address TTL key expiration?
Payment Protocol would probably be the communication format for any new meta-data. What's the likelihood of something like this every making it on the blockchain? -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn m...@plan99.net wrote:3) Whilst these payment processors currently verify merchants so the security risk is low, in future a lighter-weight model or competing sites that allow open signups would give a weak security situation: a hacker who compromised your computer could sign up for some popular payment processor under a false identity (or no identity), and wait until you use your hacked computer to make a payment to someone else using the same payment processor. They could then do an identity swap of the real payment request for one of their own, and your Trezor would still look the same. Avoiding this is a major motivation for the entire system!Let me restate that, it's a huge problem...Alice's system is compromised,Mallory intercepts a payment request being sent to Alice from payment processor X on behaf of merchant X.Mallory regenerates a spoof payment request which pays to M, from the same payment processorAlice can't tell Mallory's spoofed PR apart from Merchant X's and thinks she's paying Merchant XIt might be a bit challenging for M to generate the new PR on-the-fly without being noticed, but that's not a security guarantee.Perhaps the UI just isn't expressive enough currently to expose this situation in any way, let alone reliably alert the user to the issue, because there's no way for the payment processor to get authenticated fields other than memo into the UI.
Today the only solution is for the payment processor to strictly control the 'memo' field so Mallory wouldn't be able to make his own PR that looked exactly like merchant Y's. But maybe it's too subtle to make payment processors embed that kind of information.So is the main goal is to provide a structured way to embed this information in the PR and expect that user interfaces will display them to end users? If that's the case, I don't think we need an entirely secondary certificate, or cross signing from a secondary ECDSA key.
A poor solution: If the UI included some sort of certificate viewer, even just tied to the OS certificate viewer, and made the cert available for inspection, at least the merchant would have a chance to put some fields in there which a very advanced user might actually find. But this was discussed a while ago and I think the primary problem is the difficulty in getting a CA to let you embed any additional fields in your certificate in the first place, plus you don't want to generate a new cert for each merchant.
A somewhat better option: Some additional fields defined in an extension which are reliably shown in the UI. We could try to define specific fields, like 'DelegateCN' which would possibly override the primary CN... As an aside, I think you can never allow actually overriding the CN displayed in the UI directly, the most you can do is add another field in the UI to show this string. First I need to know it's from Payment Processor X, and then maybe we can let the payment processor make some additional claim, like yes you are paying irs.gov. You can't give the impression that Payment Processor X is not actually man-in-the-middle.Maybe the simplest would be a single field expected to contain a delimited key/value string (of course JSON) which could be shown as additional lines of labeled text in the UI. I don't want to give the "merchant" too much dynamic control over what the user's screen will display, but making it somewhat dynamic might add some future proofing.I think any additional extension fields should be hashed using the hash function specified in pki_type and signed by X509Certificates.certifcate private key. No extended_certs required -- I'm thinking something like;message PaymentRequest { // new fieldoptional bytes extended_properties = 6;optional bytes extended_properties_sig = 7;}Thanks,Jeremy--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Payment Protocol Hash Comments
From BIP70: If pki_type is x509+sha256, then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is x509+sha1, then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Positive and negative feedback on certificate validation errors
We currently have subtle positive feedback of a signed payment request in the form of the green background. Unsigned requests simply show up without the green background, as well as requests which provide a certificate but have a missing or invalid signature. There's a open bug (#3628) and pull request (#3684) to provide negative feedback (yellow background) for a missing or invalid signature, but it seems like there's some debate on whether bitcoind should do that... If an attacker can avoid the negative feedback by just stripping the signature and setting pki_type to none, then arguably there's no security benefit by singling out badly signed payment requests from unsigned payment requests. So perhaps the root problem is that the positive feedback (green background) is not strong enough to make its absence highly conspicuous to the end user. As an aside, how could we go about implementing the equivalent of HTTP Strict Transport Security for payment protocol to prevent this trivial signature stripping attack? Is this a possible extension field merchants are interested in? -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir laa...@gmail.com wrote:Such a thing would be interesting for a future BIP standard. I see one problem here: for an unsigned payment request there isn't really an "origin". Browser URI handlers don't send the referrer either.Yeah, good point. If you have a cert, we have the CN from the cert, which becomes the string displayed as 'Pay To' and alternatively 'Merchant'.But if there's no cert then all you have is memo.So the best way to differentiate signed requests is by prominently displaying that Merchant string. Really the green part should just be the 'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that would make the lack of certificate highly apparent.-- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fee drop
If I understand correctly, the risk here is this would open a historically large discrepancy between MIN_RELAY and the expected minimum fee to actually obtain block inclusion. I don't know if that's true, but I think that's what Peter is saying makes it different this time.The relay network does anti-spam with MIN_RELAY and MIN_DUST, but of course only transactions which hit the blockchain actually PAY the fee, so this allows lower-cost spam in the true dollar sense.I guess it comes down to how 'sharp' the edge is between staying above MIN_RELAY and staying OUT of the blockchain. In the worst case, there's a completely deterministic boundary, so an attacker can generate an infinite number of transactions which are guaranteed never to see the inside of a block, and so therefore completely free for the attacker, and all of which the network will relay (by default).On Tue, 25 Feb 2014 08:55:58 -0800, Mike Hearn m...@plan99.net wrote:Nodes that are encountering memory pressure can increase their min relay fee locally until their usage fits inside their resources. It's annoying to do this by hand but by no means infeasible. Perhaps this is just another way to think of the floating fee problem. What does MIN_RELAY need to be so that my local resources stay within some reasonable limit (and 'reasonable' means different things to different nodes).We have an input gate on transactions entering mempool, we persist mempool, and I don't know the specifics but, I assume there's some expiration policy other than block inclusion to clear out a Tx from mempool. But are transactions prioritized in any way after they make it into mempool today?How closely should mempool selection align with the expected block inclusion? I think if they align perfectly in theory that means optimal mempool resource allocation. For example, a miner would push out cheaper transactions which they were previously hashing against to make room for higher fee transactions (bsaed on max block size or orphan rate projections), but do we do the same for mempool? E.g. - After hitting X number of transactions, the fee has to be larger than a transaction in mempool in order to get in, - That in turn that ejects a random transaction which paid less fees than the incoming Tx from mempool - We would have to consider how ejection would work with chains of unconfirmed transactions (cumulative average fee/kb?) but again in this case, you would want to 'do what miners would do' if you couldThanks,Jeremy-- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik jgar...@bitpay.com wrote:
This PR reduces the size to 40 bytes:
https://github.com/bitcoin/bitcoin/pull/3737
Just quickly GLANCED at it, but if I understand correctly how the template
matching code works, that will change max size of the data to 40 bytes
but does not do anything to enforce most-efficient encoding.
else if (opcode2 == OP_SMALLDATA)
{
// small pushdata, = MAX_OP_RETURN_RELAY bytes
if (vch1.size() MAX_OP_RETURN_RELAY)
break;
}
This code was a bit hard for me to parse since it's not actually requiring
any data, just disallowing more than a certain number of bytes of data. So
a bare OP_RETURN would be allowed as well, for whatever good that will do.
If you want to strictly require no PUSHDATA, perhaps you could do:
else if (opcode2 == OP_SMALLDATA)
{
// small pushdata, = MAX_OP_RETURN_RELAY bytes
if (opcode1 = OP_PUSHDATA1 || vch1.size() MAX_OP_RETURN_RELAY)
break;
}
Thanks,
Jeremy
--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Longer term it would be more ideal have a canonical identifier for the transaction before it even gets to the chain to support these use cases, even if wallets are able to properly identify the status of it's transactions. -Allen One possible work-around to get back trusted transaction chaining for payment channels and locked refunds from multi-sig would be to make the initial transaction include zero fee, and depend on child-pays-for-parent in order to get the first and follow-on transactions into a block. This of course only works for protocols where the parties don't need the initial funding transaction to actually hit the blockchain right away.But this relies on two assumptions; 1) that miners won't include a zero-fee transaction in the blockchain, and 2) that miners actually implement child-pays-for-parent. It's definitely not the same security as-if you had immutable txid, but it's something to consider. 1) Mutants may cause wallet spam and difficulty calculating balance (and wallets will evolve to deal with it)2) Mutants cause DoS because they can interfere with your own transaction chains, which for example makes batch off-line processing much more difficult3) Mutants introduce a 3rd party attacker into any two-party protocol that relies on chainsThere's a lot to digest in the 'v3' transaction/block proposal. It sounds like there may be some uncertainty over whether we can *prove* that v3 transactions in v3 blocks would actually be guaranteed immutable with these changes?If we cannot fully prove a Tx is immutable, then is it actually worth taking steps to make it seem immutable, or is that just a false sense of security in the cases where chained transactions were actually expected to be reliable? Under that thinking, maybe it's best to accept mutants as a fact of life, and only consider protocols and techniques that cannot be broken by mutants.In what cases does reducing the sources of malleability, but not necessarily eliminating from a security proof perspective, actually help? Basically, if we don't know that we will succeed, isn't there really no point in trying?-- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support
Well the point of the Merkle tree is that if I all you have is the top, and all I give you is a leaf node and the siblings of all parents of that leaf, then by simply hashing you can check if the node was actually present in the tree. The only reason this works is because it's hard for an attacker to come up with the list of values which would ultimately hash together to produce the expected top value. But if the hash function is actually just XOR, it becomes completely trivial for me to claim any value I want was in the tree. 1) Pick the fake value you want to claim was in the tree (leaf node) 2) Choose some random values to fake the depth in the tree 3) Calculate the last value as 'Prev (x) Top' 4) When your victim goes to verify set membership, they will get the top value they expected On Tue, 04 Feb 2014 08:04:14 -0800, Peter Todd p...@petertodd.org wrote: On Tue, Feb 04, 2014 at 04:17:47PM +0100, Natanael wrote: Because it's trivial to create collisions! You can choose exactly what output you want. That's why XOR is a very bad digest scheme. You're close, but not quite. So, imagine you have a merkle tree, and you're trying to timestamp some data at the bottom of the tree. Now you can successfully timestamp the top digest in the Bitcoin blockchain right, and be sure that digest existed before some time. But what about the digests at the bottom of the tree? What can an attacker do exactly to make a fake timestamp if the tree is using XOR rather than a proper hash function? -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)
Consequently you can now securely and very network/space efficiently
securely delegate searching a block by computing the private key for the
IBE pub key that any sender would use for that block, and sending it as
a query to a random (or node-capture defended random selected node).
The node can decrypt the encrypted bloom baits with it, but remains
powerless to correlate with bloom baits to other payments received by
the same user in bother blocks.
I'm not sure I've fully wrapped my head around it.
d/Q- Identity key
E - Generate an epoch-pubkey: E = Q * H1(epoch)
r/P- Ephemeral privkey/pubkey, or discoverable from inputs
S = r * K - Shared secret (ECDE)
Payer derives an encryption key H(S), and encrypts M, which is a 1 byte
bloom bait.
For each epoch, payee generates e = d * H1(epoch) and provides the key to
a full node for monitoring. So you are providing a per-block or per-epoch
private key, along with the block ID or epoch ID that the key corresponds
to.
The full node then uses this privkey to decrypt the same byte in all the
transactions in that epoch/block which match the expected layout/template,
e.g. given a certain length OP_RETURN, pull the specific byte and decrypt.
This decrypted byte is then in turn used as bloom bait which may or may
not cause the transaction to be sent back to the SPV client.
Am I right in saying the full node has no idea if decryption is
'succeeding' it just feeds the resultant bait into the bloom filter and
the transaction may match or not? So we do get some level of repudiation
by the SPV client -- the server doesn't know exactly which transactions
belong to the SPV client.
The bloom bait specified in the reusable address is still making the
bandwidth/privacy trade-off, it just doesn't become public information,
because it's protected by another factor?
What encryption scheme is being used here?
-=-=-=-==
Another approach (inspired by IBE) which narrows the discoverability of
transactions to the nodes that your SPV client is actually communicating
with, for the specific blocks/epochs that you specify, would be to use
PEKS.
PEKS(Q, W) for a public key Q and a keyword W produces a searchable
encryption of the word W.
The payee holding 'd' (privkey for Q) can create a trapdoor which allows a
server to search for transactions with W, where the searching party only
knows if a match is found or not.
Payer:
d/Q - Longstanding / identity privkey/pubkey
r/P - Ephemeral privkey/pubkey, or discoverable from inputs
W - Searchable Keyword
H1- Hash function, {0, 1} ∗ → G1
H2- Hash function, G2 → {0, 1}p
Secret, as usual per ECDH:
S = r * Q
For payer to create the searchable encryption of W for Q, called 'Sw':
Sw = H2(e(H1(W), S))
OP_RETURN P, Sw
For payee to search for a given 'W', payee calculates a trapdoor 'Tw':
Tw = d * H1(W)
For a searcher, given a Trapdoor (Tw), check each Transaction (P, Sw):
H2(e(Tw, P)) ==? Sw
If the values match, the keyword matches
Without getting into the concepts of e(g,g) and binomial pairing, I think
of it this way:
Sw = H2(r * Q * H1(W)), but recall: rQ == dP, so...
= H2(d * P * H1(W)), which can be written
= H2(d * H1(W) * P)
Severs finds all transactions with 'P' on relevant parts of the
blockchain, multiplies by the provided trapdoor 'Tw', applies 'H2', and
checks for a matching 'Sw' in the transaction;
Tw = d * H1(W)
Sw = H2(Tw * P)
H2(d * H1(W) * P)
PEKS is vulnerable to an offline keyword guessing attack, where you can
discover the value of the keyword being searched, if the keyword is low
entropy. The server/attacker can figure out the value of W, but they can't
generate their own trapdoors to search for other keywords.
But in this case, the 'keyword' can simply be the block ID / epoch ID
itself, not a secret value at all. In other words, the server can only
search for your transactions within the blocks/epochs that you specify.
Using blockID/epochID as W, this would allow a server to find all
transactions belonging to the payer for that blockID / epochID. The SPV
client would simply provide the trapdoor for each block/epoch to be
searched.
There are extensions to PEKS which provide for 'fuzzy' matching but they
are 'fuzzy' within the scope of Q, not across different Q, so that doesn't
help provide any repudiation. So I see this as only slightly improving
Peter's original proposal of providing 'Q' to the searcher, but if you
want repudiation, not as good as Adam's solution.
Perfunctory disclaimer... Hopefully this is close to correct, but please
don't anyone actually try to implement this!
Thanks,
Jeremy
--
WatchGuard Dimension instantly turns raw network data into actionable
security intelligence. It gives you real-time visual feedback on key
Re: [Bitcoin-development] BIP70: PaymentACK semantics
Please note, responding to Pieter and Chuck concurrently. On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille pieter.wui...@gmail.com wrote: Currently, with the specification and implementation in Bitcoin Core, if a merchant wants to use the refund or memo feature, they need to provide an alternative route for delivering that information to them *before* the transaction is made, as sending the transaction may result in the transfer of funds without knowing what to do with it (if their receive server is down at the right time) and potnetially no way to contact the sender. This makes these fields utterly useless. This is not a matter of letting wallets experiment with the best behaviour. This is removing the ability to rely on the payment protocol being bidirectional. I think we want to separate the two issues; 1) Reliably getting refund/memo fields to the merchant/payee 2) Who broadcasts a TX, how it's retried, how outputs are 'locked' and if/when they should be [double]-spent to clear them We should be able to solve '1' without having to fully spec out behavior for 2. On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille pieter.wui...@gmail.com wrote: I don't care whether wallets broadcast the transactions or not (they can experiment with that as they like). But we should take measures to prevent a transaction for being broadcast without the payment being delivered. One way is never broadcasting the transaction yourself. Another is retrying to send the payment if delivery fails. Here is what I would suggest to add to the specification: * If a payment_uri is specified, the client must attempt to send the payment there. * If a transaction is broadcast (which is permitted even if sending the payment fails), a client should make a reasonable attempt of delivering the payment (remembering, retrying, ...). * If a paymentACK has been received, the client is no longer responsible for broadcasting the transaction (but still may). To reliably deliver refund/memo fields, we could; a) Send them as part of the initial request for the PaymentRequest/PaymentDetails b) Send them as a response to the PaymentRequest/PaymentDetails before the transaction is even formed and any unspent outputs are selected c) Send them as a response to the PaymentRequest/PaymentDetails with the UNsigned transaction, and then follow up with the signed transaction in a separate message. 'a' is problematic because while wallet software could easily append some data to the queryString, it doesn't work if the user is downloading then opening the PaymentRequest as a file. So 'a' is a no-go I think. 'b' is fine, if not overly chatty. The only thing committed is a refund address, which is a lot less problematic than committed unspent outputs. 'c' is nice because it lets the server preview the transaction (and ACK/NACK it with a memo of their own -- e.g. 'fee too low'?) without being able to broadcast it, so we know unspent outputs are not yet committed. But all of these require too many changes to the protocol for my liking. On Wed, 29 Jan 2014 21:47:51 -0800, Chuck chuck+bitcoin...@borboggle.com wrote: 3. Customer builds a set of transactions and sends a new PaymentApprovalRequest message which includes a refund address and the unsigned transactions and their associated fully-signed transactionhash, the whole message signed with the private key of the refund address. Unsigned transactions and their associated fully-signed transaction hash -- isn't that a fully signed transaction? In this case, it doesn't solve the core problem of the server being able to broadcast that transaction without ACKing. On Wed, 29 Jan 2014 21:47:51 -0800, Chuck chuck+bitcoin...@borboggle.com wrote: In Step 3, it's critical the customer sign the message with the private key of the refund address, so that the merchant can be confident the refund address is correct. For merchant confidence that the address is correct, we can leave the transport security to the transport layer. For payer proving refund address was X after merchant sends a refund to Y, that's a different story. I don't think we want to *require* access to the refund address private key. For example, BIP32 public derivation may have just the pubkey available. Offline transaction signing is one thing, but offline PP message signing is too much. I think there are better ways to secure the refund address which can reuse existing code, and certainly the option should remain to send a plain refund address just relying on transport security and trusting the merchant. -- WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in
Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach andr...@schildbach.de wrote: On 01/27/2014 06:11 PM, Jeremy Spilman wrote: SCAN TO PAY For scan-to-pay, the current landscape looks different. I assume at least 50% of Bitcoin transactions are initiated by a BIP21 URL encoded into a QR-code. Nevertheless, I tried to encode a payment request into the bitcoin URL. I used my existing work on encoding transactions into QR-codes. Steps to encode: Really interesting work. When using scan-to-pay, after the payer scans the QR code with the protobuf PaymentRequest (not a URL to download the PaymentRequest) are they using their own connectivity to submit the Payment response? How about putting a Bluetooth address in the payment_url inside the PaymentDetails message for the smartphone to send back the Payment response and get PaymentAck? That's exactly what I have prototyped. I am putting a Bluetooth MAC address into the payment_url. Have a look at the TAP TO PAY paragraph for details, its mostly the same mechanism. Same mechanism for both, of course. Sorry, that was obvious. :) -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bait for reusable addresses
I think we need to provide users with better options than that. Perfect privacy without extraordinary computational overhead today means downloading everything. But we could provide better tools to *shift* bandwidth requirements rather than try to reduce them. I've been thinking about a setup where user runs a UTXO only, and maybe even outbound-connect only (like bitcoinj), full node at home. Then using Tor, mostly for tunneling, they host a hidden service they can connect back to from their smartphone to see balances, manage receive addresses, send funds, etc. The smartphone is not doing SPV, it's like a web client for the wallet running at home. The initial connection between the smartphone and home wallet has the phone learn two codes, one is the hidden service name, another is an access token which is revocable. You may require further authentication from that point. With fast bootstrapping / checkpointing of the UTXO I think usability could be as good as SPV, and you would get push-notification of relevant transactions with zero privacy trade-off. I wonder if people would want to run such an app, if they would run it on their desktop, a dedicated machine, or an old smartphone or other cheap ARM device. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell gmaxw...@gmail.com wrote: I'd point out that regardless of how long the desired prefix is, the encoded prefix should probably always be constant length in all reusable addresses. I might be misunderstanding, but I think prefix length must be specified in the reusable address, however I agree the prefix actually published to the blockchain should be constant length. If you don't want a particular prefix then the sender should just pick random data for the rest of the space. There is no need to publish any additional distinguishing data in the form of how long the prefix is. Let's say the payee's reusable address is 'version prefix Q1 Q2 ...', where prefix is 2 bytes. Without any length indicator. What's the payer going to put on the blockchain? How would they know what the 'rest of the space' is? They would have to put the whole prefix verbatim into the OP_RETURN without knowing how many bits of prefix the payee actually wants to see there. If instead, the address is 'version prefix prefixLen Q1 Q2 ...' where prefix is 2 bytes, and prefixLen is 1 byte, representing number of bits of prefix that should be fixed. Then payer will know how much of prefix from the address should be taken verbatim, and the rest of the two bytes would be replaced with random data, and exactly two bytes would be put in the OP_RETURN. If prefixLen was zero, the 2 byte prefix in the reusable address must be ignored, and an entirely random 2 byte prefix would be put into the OP_RETURN. I'm a bit worried about broken implementations copying the prefix from the reusable address into OP_RETURN when prefixLen is 0, and ending up basically identifying the payee. That's the only reason I can think of to make 'prefix prefixLen' optional in the reusable address, to prevent the opportunity to screw it up. You would *still* put a 2-byte random prefix in the OP_RETURN, even if the fields weren't in the address at all. It's just a minor concern though. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner etothe...@gmail.com wrote: Isn't there a much faster asymmetric scheme that we can use? I've heard people talk about ed25519, though I'm not sure it can be used for encryption. Doing ECDH with our curve is within a factor of ~2 of the fastest encryption available at this security level, AFAIK. And separate encryption would ~double the amount of data vs using the ephemeral key for derivation. Using another cryptosystem would mandate carry around additional code for a fast implementation of that cryptosystem, which wouldn't be fantastic. So I'm not sure much can be improved there. In the case where payment is being sent only to Q1, and Q2 is for discovery only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20 byte vs 32 bytes in the OP_RETURN, and of course faster multiplication. 80-bits of security I assume still greatly exceeds the actual level of privacy you get with the overall solution, and since Q2 is never protecting actual funds... But if it's a real weakening of the privacy then definitely not worth it, and even the added complexity of another curve seems possibly not worth it... -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
I hear you, and I really don't care that much what it's called, as much as, does it work and how! I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. Regardless of what it's called, Blockchain.info should tell the user, hey this address doesn't let the whole world see every single payment that's made to it! If you paid something to this address, only you know how to find the payment - look for the stealth address in your transaction list. So if we call the address that has the pubKeys the reusable address and the address that's generated from the shared secret the stealth address then is everyone happy? :-) -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Might I propose "reusable address".I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'.It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted.I think it meets all the criteria required: - Communication between parties is a single message from the payee, which may be public - Multiple payments to the same address are not publicly linkable on the blockchain - The payee has explicitly designated they expect to receive more than one payment at that address - Payer can publicly prove they made a payment to the reusable address by revealing a secretI have high hopes for this feature. The war *against* address reuse may soon be a distant memory.On Wed, 15 Jan 2014 12:44:17 -0800, Jeff Garzik jgar...@bitpay.com wrote:"static address" seems like a reasonable attempt at describing intended use/direction.On Wed, Jan 15, 2014 at 3:38 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport bendavenp...@gmail.com wrote: But may I suggest we consider changing the name "stealth address" to something more neutral? ACK. Regardless of the 'political' overtones, I think stealth is a little cringe-worthy. "Private address" would be fine if not for confusion with private-keys. "Static address" is perhaps the best in my view. (also helps improveawareness that normal addresses are intended to be more one-use-ness)-- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back a...@cypherspace.org wrote: I was meaning to comment on the SPV privacy properties. For full-node use these unlinkable static addresses have quite nice properties. It also nicely solves the problem of having to educate users and wallet authors to not reuse addresses. But for SPV nodes they have no direct-way to find the payments. So then in Peter Todd's variant (maybe it was suggested by Greg Maxwell?) there is a second address so that the SPV client can delegate detection to a full node without giving it the private key allowing it to spend! (This is something analogous to bloom filtering). The second pubKey is useful for delegating scanning, or even just being able to scan for transactions yourself without keeping bitcoin-encumbered private keys decrypted in memory. So even while running your own full node there are good reasons to use a second pubKey to derive the shared secret. But I think its moderately expensive for the full node because it has to do a DH calculation per transaction and its not precomputable so there is IO per query. (In the P version in fact only payments which are thereby reconizable as unlinkable static need to be processed). And of course, if you have multiple reuseable addresses, then you're doing this calculation separately to check each one. So the load on a popular centralized service would be quite high, which you may consider a feature. Then an artificial prefix is proposed to constrain the query to a subset, however that leaks to everyone so in some ways its a worse privacy leak than bloom filtering. It can be used to rule out recipients and could be quite a powerful extra lever for statistical analysis. Choosing how many bits to put in the prefix may be difficult, particularly if transaction load changes dramatically over time. 0 or 1 bits may be just fine for a single user running their own node, whereas a central service might want 4 or 5 bits to keep their computation costs scalable. But I think it's great people can choose how to trade privacy for computation/bandwidth however they want, and services can compete to offer monitoring for 0+ bit prefixes. (And also there is proposed a version of the prefix computed via brute-force to make it somewhat stealthy still). I think in this case the hash grinding of the prefix would only being used if thats how transactions are being indexed. I don't think it adds any privacy, it's just added work we're forced to do in order for the prefix to work as designed. Peter, please correct me if I'm wrong. Maybe in the payment address case the service should choose the derivation factor and communicate it and the client with the static address, as suggested by Alan Reiner because then it can also serve the function of allowing the service to tie the payment to the users account. I think any change which requires more than a single published public message (e.g. a posting in a forum, or in a README.me in Github) should be seen as solving an entirely different problem. If you have directed communication from payee-payer, I think there's simply no reason to do it this way. (By this way I mean ECDH with OP_RETURN P). We could try to define a different reusable address type, for when you can make a single directed message from payer-payee, and in that case there's probably no need for ECDH or the prefix, like Alan's proposal. But once you admit having that directed communication, then you are swimming very close to the payment protocol. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd p...@petertodd.org wrote: On Mon, Jan 13, 2014 at 02:02:00PM -0800, Jeremy Spilman wrote: I decided to put both pubKeys in a 2-of-2 multisig, instead of keeping one of the pubKeys in the OP-RETURN, to prevent a malicious sender from triggering false positives on your online detection key when the funds are actually still fully controlled by the payer. You can still have a false positive (only 1 of 2 keys actually yours) but the funds would be trapped so it's unlikely anyone would do it. How would they trigger false positives? The payee recovers the nonce with ECDH from the payor's ephemereal pubkey and their online detection secret key. They use BIP32 public derivation with their offline spending pubkey(s), if the derived pubkeys match the actual scriptPubKey they know the output is spendable by them. I don't see how that can go wrong. Right now I have this: byte[] e = EC.NewPrivateKey(); byte[] P = EC.GetPublicKey(e, compressed: true); byte[] S1 = EC.DH(e, Q1); byte[] S2 = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S2)); stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(.995), 2, 2, q1New, q2New)); stealthTx.Vout.Add(TxOut.OpReturn(P)); In this case, you can scan with d2, calculate S2, and matching payments will have the right 'q2New'. But you need to check again offline with d1 since it's a separate shared secret. Maybe you are saying: byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S)); But the payment would have (q2New - q1New) == (Q2 - Q1), so I think not entirely stealth? OK, let's fix that by adding a counter to the hash function... byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S || 1)); byte[] q2New = EC.PointAdd(Q2, Util.SingleSHA256(S || 2)); stealthTx.Vout.Add(TxOut.PayToMultiSig(Util.Amount(.995), 2, 2, q1New, q2New)); stealthTx.Vout.Add(TxOut.OpReturn(P)); This is assuming we want to put q2New somewhere into the transaction, which, is it even required? byte[] S = EC.DH(e, Q2); byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S)); stealthTx.Vout.Add(TxOut.PayToPubKeyHash(Util.Amount(.995), q1New); stealthTx.Vout.Add(TxOut.OpReturn(P)); I'll wait for ACK and then update my sample code. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back a...@cypherspace.org wrote:
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?
Adam
Thanks for reviewing this. The relevant line:
byte[] q1New = EC.PointAdd(Q1, Util.SingleSHA256(S1));
SingleSHA256 is a single application of SHA256 -- named so since 'SHA256'
functions in many Bitcoin libraries too often actually run DoubleSHA256.
32 bytes are returned.
The multiplication by 'G' that you mention is part of my EC.PointAdd...
I should probably just publish all my code as MIT and be done with it ;-)
Thanks,
Jeremy
public static byte[] PointAdd(byte[] point, byte[] scalar, bool compressed
= true)
{
var point1 = new OpenSSL.Crypto.EC.Point(EcGroup, point);
var num = OpenSSL.Core.BigNumber.FromArray(scalar);
var point2 = OpenSSL.Crypto.EC.Point.Multiply(EcGroup, num,
EcBnContext);
var result = point1.Add(point2, EcBnContext);
if (compressed)
return result.GetBytes(ConversionForm.Compressed);
else
return result.GetBytes(ConversionForm.Uncompressed);
}
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of Concept
On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn m...@plan99.net wrote:Cool!On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote: I spent 1BTC on TestNet to a stealth address... TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c... but can you redeem it?But of course!Every time the test runs it makes a new ephemeral key, so I wrote a separate test with hard-coded values from the block chain (as it would be in real-life) to create a redeeming Tx. I've added the RedeemStealth code to the Gist.It sent successfully using sendrawtransaction, TxID: ed92364d2b6f6528dea32dbf6c4d5d6291b601aff1ddb4eeb124d003c7c7ff07I'm self mining since no one else seems to be on TestNet this time of night... going to catch some sleep, hopefully by the time I wake up it'll be on the chain. Code which generated this transaction is here: https://gist.github.com/jspilman/8396495That's rather interesting code. Is this using a private C# bitcoin implementation?Indeed it is. One day I may publish the libraries, but they aren't doing anything particularly special under the hood, just the standard Bitcoin/EC/BIP32 stuff and using OpenSSL under the hood instead of the more typical BouncyCastle.I just tried to keep things extremely concise in the APIs. Hopefully all the function calls are obvious what they are doing. Since there's no actual wallet behind it, the code to setup the inputs is a bit annoying, but actually building and signing transactions is super clean.I wonder if the 0BTC OP_RETURN transactions should be hidden from the Transaction List?Yes, of course. The transaction list should just say something like "Payment received from Jeremy, 0.1 BTC"In this case I'm just looking at the payee wallet, but yes, "Payment set to Jeremy" should be possible, with the name coming from the CN. Maybe the simple way to punt on this is to just show 'Merchant' in the address column if it is available and an address is not.I am surprised it's not already the case! Though "merchant" is perhaps a bit biased as a name, internally it perhaps should just be called "Recipient". There's no requirement for you to be a merchant to create payment protocol requests.Yeah, right now for PaymentProtocol fulfilled payments, on the payer's Transaction List, it shows the address in the 'Address' column, but if you right-click and look at 'Transaction details' you will see something like: Status: 42 confirmations Date: 1/12/2014 21:07 To: mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV Debit: -0.10 BTC Net amount: -0.10 BTC Transaction ID: 93c50347e35062a3501fcea15d1a22ace8d1b059affb9913fc9e7df4e7d6a00b-000 Merchant: www.bitcoincore.orgI agree 'Merchant' might not be the best name, especially since when you're making the payment the field is labeledsimply 'Pay To'.But I think we agree, why show 'mrhz5ZgSF3C1BSdyCKt3gEdhKoRL5BNfJV' in the transaction list instead of just"Paid To: www.bitcoincore.org" and then perhaps the Memo field could be stuck under 'Transaction details', instead of losing that important bit of info. I can probably make the necessary changes to IsMine, but I don't know where we should keep 'd2'/'Q2' unencrypted so it's available for doing the necessary tests, but has no chance of ever be used as a stand-alone private key?The wallet format would need extending.I'd feel a lot more comfortable if the protocol was reviewed by a professional cryptographer though. I think think Gregory already brought up an issue to do with people able to detect such payments by testing if decrypted values are points on the curve, or something like that. Not sure I follow that, will look forward to hearing more about it.The only risk I know of is that there are checks in theory that you would do on Q1/Q2, but since the payee is the one generating Q1/Q2 they would literally be attacking themselves. I referenced two papers in a prior email specifically on reusing ephemeral keys in ECDH, and the validation you need to do on Q1/Q2 when re-using an ephemeral key to send two messages to two different pubKeys. I think the idea of checking the pubKeys when re-using ephemeral keys is more when the pubKeys are under the attackers control. But the validation is not complicated, and I'll see if I can add it tomorrow.It would be good to fully understand how a possible small-group attack would work... This is a bit of guess-work on my part: If a payee managed to foot-shoot themselves with a bad Q2 pubKey, then gives out d2/Q2 to a scanning service run by Mallory... Mallory has d2/Q2, given P from a transaction, he calculates S2 (as usual): byte[] S2 = EC.DH(d2, P); But with the small sub-group attack with Q2 he can learn 'e' (the ephemeral private key) used: byte[] S2 = EC.DH(e, Q2); and from that he can calculate S1 directly, when he should only know S2. byte[] S1 = EC.DH(e, Q1); So does that mean Mallory can find 'd1'? It looks like you would need another small sub-group attack on P, the ephemer
Re: [Bitcoin-development] Stealth Addresses
Oh, sorry, I forgot to mention it in my first write-up but you can easily make stealth addresses include a second pubkey for the purpose of the communication that either isn't used in the scriptPubKey at all, or is part of a n-of-m multisig. (n=2) Interestingly that also means you can give a third-party that key and out-source the effort of scanning the blockchain for you. Great point. Even if it's not a 3rd party, I think it's really important to be able to scan for transactions with a key which can't actually spend the funds. The first approach is just one-pass ECDH. I think you're saying the second approach is two rounds of ECDH but re-using the same e/P (usually referred to as r/R in ECIES). I think this is safe, unlike reusing an ephemeral key for signing operations. Payee: Publish Q, Q2 [d, d2 are privkeys, Q, Q2 are pubkeys] Payer: 1) Generate ephemeral key: e / P [e is privkey, P is pubkey] 2) S = e * Q [first shared secret] 3) S2 = e * Q2[second shared secret, reusing 'e'] 4) Q' = Q + H(S) [pay-to stealth address] 5) Q2' = Q2 + H(S2) [stealth 'marker'] Watch: 1) Look for TxOut with OP_RETURN P 2) Q2' = Q2 + H(d2 * P) 3) Check for Q2' elsewhere in the Tx S/MIME for example, allows reuse of the ephemeral keypair. When reusing an ephemeral keypair where A reuses (x, X) to encrypt different messages to more than one user, A should verify the static public keys to prevent small-subgroup attacks.[1][2] Let's say you pay-to Q' and then Q2' value has to be somewhere else in the transaction. You could put it next to the shared P in OP_RETURN. OP_RETURN P Q2' would be 66 bytes. But then Mallory could generate transactions with the right Q2' but with his own pubkey in Step 2 instead of Q. So your scanner would detect a payment, but you wouldn't be able to spend it, and Mallory could. That's a good argument for putting Q2' in a 2-of-2 multisig so that pulling this trick would at least make the transaction unspendable for both parties, which may be good enough deterrent, but you're still going to want to check it against your 'd' before fulfilling a large order. Your online watch process could queue the matching transactions, which you could move to your offline machine, decrypt your key, and verify the transactions are spendable. Now, you would need to get two pubkeys to the payer, throw in a prefix to help standardize it, and end up with addresses that could look like (for example): xSTLxsn59oaupR6ZKt2yddQ4dp5hcFinnTWkvsDiXtHgAEDg5ajNVzTY8MMQsmqnEn3ZMKxQzrfC3pDimfTWMkiUb7x3jX3J26JSX tSTLcpwzupCFL3maVZkSiB9ib3BXsCAfkhMLgckQEyoj8Tk83ANzofeuDdbX6bSPqNRfACLLFYK8EwVo1jdjxNDFNDWxhnQiAy4ba Those addresses are 74 bytes: PrefixCompressedPubKey1CompressedPubKey2Checksum xSTL Prefix = 0xC0CB9270 tSTL Prefix = 0xB2E27D50 NOTE: I do NOT have the corresponding privkeys for these four pubkeys! Those just happened to be the first matching prefixes I found for 74 byte addresses. I could try to find ones which start with a specific byte if that's somehow better, like 0x04 to match BIP32. Unfortunately, I don't think you can just derive a second public key from the first to keep the address shorter, and still keep the first private key secure, even if the second private key is stolen. You only get equivalent security as BIP32 public derivation, where you can't lose a child private key. Do we also want xSTL (or whatever user friendly string) prefixes for single pubkey (41 byte) stealth addresses? I'll wait a couple days for feedback, then I'll try to implement the following prototypes: 1) Pay to STL addresses 2) Watcher process to detect and queue STL payments for a given d2/Q2 3) Offline verifier to take output from Watcher and verify spendable given encrypted d/d2 Obviously extending QT directly for #1 would be ideal, I may even be able to do that since supporting a new address type should be fairly contained. But if not I'll punt to writing a node.js or python script which connects to bitcoind via RPC. Thanks, Jeremy [1] - On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols http://www.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf [2] - Validation of Elliptic Curve Public Keys http://www.iacr.org/archive/pkc2003/25670211/25670211.pdf -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list
Re: [Bitcoin-development] Stealth Addresses
Thanks Peter for the paper! I'm just going to restate your 'simple explanation' to make sure I got it... The payee publishes a public key of theirs, which will be a long-standing identifier, public key = 'Q', corresponding private key = 'd'. To pay them, payee generate a keypair, private key = 'e' public key of 'P'. Publish 'P' in the transaction. The payer can calculate S = eQ, where S is a shared secret between payer/payee. The payee calculates the same S as S = dP. So the payee sees 'P' in a transaction, and multiplies by their private key, to get S. Now that we have the shared secret, either side can calculate an offset to Q which becomes the pay-to-address. When you say BIP32-style derivation, Q' = H(S) + Q, does this mean Q + SHA256(33-byte S)? A payee has to check each transaction (or every transaction of a fixed prefix) with 'P', calculate Q' = Q + H(dP) and see if that transaction pays to Q'. If the address matches, then the payee can spend it with private key of d + H(dP). One downside is that you have to hold your private key in memory unencrypted in order to identify new payments coming in. So stealth-addresses may not be suitable for receiving eCommerce payments, since you can't implement a corresponding watch-only wallet, e.g. there's no way to direct-deposit into cold storage. Hope I got that right... On Mon, 06 Jan 2014 04:03:38 -0800, Peter Todd p...@petertodd.org wrote: Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared secret that the payee can use to recover their funds. Let the payee have keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be used to derive a ECC secret key, and from that a scriptPubKey, however that would allow both payor and payee the ability to spend the funds. So instead we use BIP32-style derivation to create Q'=(Q+c)G and associated scriptPubKey. As for the nonce keypair, that is included in the transaction in an additional zero-valued output: RETURN P -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Privacy and blockchain data
2) Common prefixes: Generate addresses such that for a given wallet they all share a fixed prefix. The length of that prefix determines the anonymity set and associated privacy/bandwidth tradeoff, which remainds a fixed ratio of all transactions for the life of the wallet. Interesting thought to make the privacy/bandwidth trade-off using vanitygen and prefix filters. But doesn't this effectively expand the universe of potential spies from 'the global attacker' who is watching your SPV queries, to simply 'the globe' -- anyone with a copy of the blockchain? Some stats on UTXO set size: (slightly stale -- as of block 270733) 7.4m unspent outputs 2.2m transactions with unspent outputs 2.1m unique unspent scriptPubKeys Side note: the top 1,000 scriptPubKeys have 10% of all unspent outputs. Let's say you use an 8-bit prefix (1/256) that would be ~10,000 transactions in the UTXO you would be monitoring. But if I knew a few different days / time-periods you transacted, I could figure out your prefix. Of course, anyone you transact with would know your prefix outright. Wouldn't this also allow obvious identification of spend versus change addresses in a transaction? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
So I looked into gitian, the first thing I noticed was the hashes that people were signing, for example: https://github.com/bitcoin/gitian.sigs/blob/master/0.8.6-win32/gavinandresen/bitcoin-build.assert don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually hosted by sourceforce. That was a bit alarming at first, but I talked to BlueMatt and maaku on IRC and the difference is due to Gavin Authenticode signing the executable for windows. BlueMatt asked if someone could implement in gitian-downloader a way to strip off the signature so that we could get back to the raw binary with a hash that matches what everyone is producing from gitian. I found: http://blog.didierstevens.com/programs/disitool/ which is a Python script which can strip the signature nicely, but the hashes still don't match. I couldn't find a gitian build of 0.8.6 so I built my own, and after verifying the hash for v0.8.6 was '49547ff9...' as expected I looked at the hex diff between that and the sig-stripped .exe from sourceforge, and the only two differences are: - At offset D8 the stripped file has '5D E2 B2' versus 'F9 F4 00' in the gitian build - The sig-stripped file has an extra byte '00' at the end I started to look at the file spec for windows PE files and quickly thought better of it. Maybe someone better informed can chime in on what those three bytes at offset D8 specify. I'm not sure if we want to patch the signature onto the gitian build, or strip the signature off of the Gavin-signed build, but something of the sort is necessary if you want get gitian-downloader to match the official distro (for Windows at least). In any case, I think wallet users want to know when an upgrade is available, and ability to click an 'update' button get a binary they can trust. It's not a problem unique to bitcoind, deterministic builds are awesome, but I don't think fully solve it. Thanks, Jeremy On Tue, 31 Dec 2013 13:33:54 -0800, Matt Corallo bitcoin-l...@bluematt.me wrote: We already have a wonderful system for secure updating - gitian-downloader. We just neither use it not bother making actual gitian releases so anyone can use it to verify signatures of downloads. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I didn't know about the dedicated server meltdown, it wasn't any of my infra. Anyway, my previous offer still stands.One less 'security theater' approach would be if we could provide forward-validation of updates using the blockchain. It's always going to be up to the user the first time they install the wallet to verify the provenance of the binaries/source. From that point forward, we could make it easier if the wallet could detect updates and prove they were valid.This could be as simple as hard-coding a public key into the client and checking a signature on the new binaries. But it could also be more interesting...For example, a well known address on the blockchain corresponds to multi-sig with keys controlled by developers (or whatever key policy the release team wants to impose). A spend from that address announces a new release, and includes the expected hash of the file.You would probably need some way to handle the different release targets. A more rigorous approach could identify all the various releases in terms of a BIP32 xpubkey whose branches would correspond to the different release trains and platform builds. Spends from a node announce the release and the expected hash.This provides zero benefit if the wallet software is already compromised, but I think this would allow trusted automatic update notification, and a trusted way to deliver the expected hashes. It also might resolve some of the consternation around when a release is truly "released", if that's really a problem.I'm not sure how far along the slope you would want to go; 1) announcing updates in the UI, 2) providing a button the user could click to verify a binary matches its expected hash, 3) click to download and verify the upgrade matches the expected hash, 4) click to upgradeFormalizing the release process around a set of privkeys (or split shares of keys) may raise its own set of questions.For the download itself, I've heard the advocates of announcing availability on the blockchain leading to a BitTorrent magnet link, but I also understand objections to adding an entire BitTorrent stack into a wallet.On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote:The site was actually moved onto a dedicated server temporarily and it melted down under the load. I wouldn't call that no progress.Oh, it did? When was that? I must have missed this excitement :)Any idea how much load it had? Perhaps I wasn't clear on the point I was making Drak's threat model is not improved in the slightest by SSL. It would be improved by increasing the use of signature checking, e.g. by making it easier.Well, that depends. If you watch Applebaums talk he is pushing TLS pretty hard, and saying that based on the access to the source docs some of their MITM attacks can't beat TLS. It appears that they have the capability to do bulk MITM and rewrite of downloads as Drak says but *not* when TLS is present, that would force more targeted attacks. So to me that implies that TLS does raise the bar and is worth doing. However if we can't find a server that won't melt under the load, then that'd be an issue. We could consider hosting downloads on AppEngine or something else that can handle both high load and TLS. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Access to Mempool
I was reading there are some commands to access a peer's mempool state. The purpose being to allow miners to recover faster after a reboot, I think? Reading peer mempool definitely allows recovering faster after a reboot. So does persisting mempool in a database locally. But what can you learn about a node from its mempool? Basically, are there distinguishing features in the mempool, or could there be? Are there transactions you can receive which go into your own mempool but which you don't forward? How about 'nLockTime' transactions? Is this new feature off by default? Which clients support it? By the way, are there recommended places to go to compare features implemented by different wallet software? Sorry, so many questions... -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Peer Discovery and Overlay
Some really nice efforts out there to map and analyze the bitcoin P2P network. The current protocol apparently recommends returning up to 2500 addresses from 'getaddr'. I'm not sure how much clients are expected to probe the address space in order to select 'far-apart' peers, or how much such an process would even attempt to achieve. How much does it matter if the ability to discover the entire network of peers is fast or slow? There are probably pros and cons to both. Is there any thought to how existing bitcoin node relations, and the ease at which peers can be discovered, becomes a service in itself, or even possibly a vulnerability? Are there any past instances of applications hijacking or interfacing with the exiting p2p messages, or abusing 'getaddr' functionality? Are there any guidelines on this, or should there be? -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
I can provide the server hardware and colocation (space, power, and bandwidth) if dedicated 50Mbit in 55 S. Market, San Jose, CA data center is acceptable.If it needs more bandwidth than that, in a few months I hope to be getting space in LA with 1Gbit, but I can't commit to that now.On Sun, Dec 8, 2013, at 03:11 PM, Drak wrote: It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github The bitcoin.org domain is controlled by me, Sirius, and an anonymous person. Control will not be lost if Sirius becomes unavailable. SSL is probably a good idea, and it's probably also a good idea to separate bitcoin.org from Github. I don't know that I trust Github. I'm sure that you can find a sponsor for a dedicated server. Let us know if DNS changes to bitcoin.org are required. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
allowfee: Allow up to allowfee satoshis to be deducted from the amount paid to be used to pay Bitcoin network transaction fees. A wallet implementation must not reduce the amount paid for fees more than allowfee, and transaction fees must be equal to or greater than the amount reduced. minfee: Pay at least minfee satoshis in transaction fees. Wallet software should add minfee to the amount the user authorizes and pays, and include at least minfee in the transaction created to pay miner's transaction fees. Wallet software may request that the user pays more, if it must create a complex transaction or judges that minfee is not sufficient for the transaction to be accepted by the network.. Thanks for the draft specs Gavin. Very clear and precise. Personally I think 'allowfee' is more useful than 'minfee'. The 'allowfee' tells me something very useful and definitive about what the merchant will let me do when making payment, and if the merchant chooses 'allowfee' intelligently, they can provide real value to their customers without exposing them to undue risk. A 'minfee' field on the other hand, is just a data point for the wallet software to consider, and likely to be noisy enough that wallets will tend to ignore it. (e.g. like Drak's example of Gox's 0.001 fee) The sender's wallet software will always be free to choose the fee, and paying less than the 'allowfee' or 'minfee' can still get a TX included in the next block. I think of the PaymentRequest is a part of the purchase contract. If a payer transmits a transaction before 'expires' but with less than 'minfee', which gets included in the next block, have they failed to meet the terms of payment? If there is some time criticality, for example to reduce exchange rate risk, then a wallet might need to choose a higher fee to ensure the transaction clears in time. Instead of 'minfee' I'm thinking it would be more appropriate to communicate this using the existing 'expires' field -- in other words, let the merchant express what their requirement is, not tell the wallet how to achieve it. In the case of a transaction with too-low fee, either the payer can double-spend with a higher fee, or wait longer for the transaction to make it into a block. If it hits the blockchain before the 'expires' time, then the merchant should have no standing to refute it, regardless of the amount of fees paid. A refund comes into play if a payer reduced the total amount in excess of an agreed upon 'allowfee', or if the transaction doesn't hit the blockchain until after 'expires'. It should be clear in these cases that payer would end up eating the fees in both directions. But then, what if a wallet pays the 'minfee' and broadcasts 1 block before 'expires' but the payment DOESN'T make the block? Is the merchant liable for too-slow transactions due to their own insufficient 'minfee' value? So I see 'allowfee' as extremely useful, but 'minfee' as somewhat problematic. Thanks, Jeremy -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.
Great paper Ittay, thanks for all your work on this. Today the threshold is 0% with good connectivity.Fig. 2 captures this well, the threshold is only zero if 'y' is 1. In Section 6 and 6.1 you argue y - 1 but the sybil attack you describe, isn't that more like how *all* sophisticated miners would want to ensure their blocks are widely propagated? I think you can't assume only the selfish miner is doing it.Based on the current 'first seen' algorithm, as you say, competing longest chains happen about every 60 blocks. The rest of the time, a single block propagates through the vast majority of the network 'uncontested'. If there are multiple valid longest blocks being simultaneously propagated, then propagation pattern of the competing blocks will determine hash rate on each.Selfish mining requires exploiting the race condition between learning about a competing block, and publishing your own. Usually we talk about minimizing publishing latency so that your block ends up uncontested 59/60 times, and in the 1/60 times, even then your block has the best chance of winning.Selfish mining forgoes the 59/60 chance of your block being uncontested, and instead chooses to 'race the network' every time. You start 'one step behind' the competing block (since of course you only learn about it after it starts propagating), so you must rely on being able to outrace propagation of the competing block through a private low-latency side-network which can inject your block at multiple points throughout the bitcoin p2p network to outrace the competitor.I think it's a stretch to say 'y' is 0 with good connectivity. Even the best connected mining pools today are concerned with this 'y' factor.Here's a probably very dumb idea... to throw out one possible "solution"...You want a way to fake-out the 'selfish miner' into disclosing their blocks -- how can your force their hand to prevent them from accumulating longer private chains?What if you propagate (and relay) an encrypted block header which honest miners will timestamp when they receive it, then 10 seconds later propagate the decryption key to unblind it. But here's the catch - maybe the decryption results in junk, maybe it results a new longer block. If it's a real block then it gets priority based on when the ciphertext was received instead of when the decryption key was received. Now 'selfish miner' can't race the network anymore, because they are always in state 0' and can't tell if they are up against a ghost, or a real competing block. If they wait for the decryption key to check, it's too late, and they are guaranteed to lose unless they can out-race the network, e.g. back at t=50%. Of course there would need to be some way to anti-DDoS this which allows for some amount of these fake-outs without letting them get out of hand.Thanks,Jeremy-- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Making fee estimation better
Do you think we're at the point where wallets have to be able to actively bid the fee using replacement due to block contention? I think a fee estimation API is just a data point. Depending on the properties of the estimator, and how that's presented in the UI, it could serve to either increase or decrease the need for recovery. Like you said, we already have fee estimation in the form of user, please estimate the fee! Now we want to make fee estimation better, and one key aspect of better fee estimation is decreasing the need for recovery. Techniques like signing multiple transactions with different fee levels should become less useful the better you are at estimating the fee. What I find interesting is that fee estimation can look at the size and type of the transaction, the age of the inputs, the number of inputs versus outputs, amount of the outputs, factor in [assumptions about] what fee policies miners are actually using, and after all that, look at the actual competing transactions on the blockchain and try to figure out how many of those are even real. For example, if you just look at fee-per-KB of mempool versus fee-per-KB of recently mined transactions, without taking into account input age, number of inputs vs outputs, output amounts... all the other things miner might have used to discriminate between transactions, then I don't think you'll end up with a better fee estimator. Contention might bump you out of a few blocks, but if the basis for calculating the fee is fundamentally compatible with the relay policies and the transaction-inclusion policies being run by large mining pools, the transaction isn't dead, it's just pending. On Fri, 25 Oct 2013 09:13:23 -0700, Peter Todd p...@petertodd.org wrote: On Fri, Oct 25, 2013 at 02:02:35PM +0200, Andreas Petersson wrote: Worth thinking about the whole ecosystem of wallets involved; they all have to handle double-spends gracefully to make tx replacement of any kind user friendly. We should try to give people a heads up that this is coming soon if that's your thinking. If there is a situation where wallets are supposed to constantly monitor the tx propagation and recreate their transactions with different fees, this would make a lot of usecases inconvenient. half-offline bluetooth transactions, users with unstable connections, battery power lost, etc, etc. - and last but not least power concerns on hardware wallets on the bitcoincard (tx signing drains a significant amount of power and should therefore only be done once) Anyway, as I've said repeatedly my problem with fee estimation is that it needs to be combined with some form of transaction replacement to give users a way to recover from bad estimates, not that I think the idea shouldn't be implemented at all. After all, we alrady have fee estimation: wallet authors and users manully estimate fees! This particular case is a nasty one re: recovering from a bad estimate, and it's exactly why the payment protocol is designed for the sender to give the receiver a copy of every transaction they make so the receiver can be held responsible for getting them mined, eg. with child-pays-for-parent, out-of-band fee payment, or maybe even by adding inputs to the transaction. (SIGHASH_ANYONECANPAY) -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
in BIP30 - if you don't read BIP30 you very likely totally miss that, until your code throws exceptions while processing block 91842. And perhaps the hardest kind of BIP of all is the lets get wallets to add this user-facing feature where it has no bearing on the blockchain or transaction processing, it doesn't make the network more resilient or add crucial functionality for increasing scalability. Kind of like JPK's HD wallet encryption proposal, which I love, and I tried to contribute to in the forums, but I can totally understand the headwinds for making progress on BIPs like that one and BIP39. No one is against it per-say, it's just much harder to articulate and justify the NEED for everyone to implement, test, and support this new not-yet-standard, nice-to-have feature. For those kinds of BIPs you probably have to go out and get some wallets to implement it, or implement it yourself, to prove the value and kick start critical mass before you will even get enough support for getting a BIP number assigned. IMO, it's not a Bad Thing. TL;DR; The current support systems worked very well for me. I was able to accomplish all my goals, and I would even say it was a pleasure. Keep a high bar for assigning BIP numbers. And I hope to be able to jump back in and do more with Bitcoin soon. Thanks all, sorry if I'm rambling, Jeremy Spilman On Thu, 24 Oct 2013 04:11:05 -0700, Christian Decker decker.christ...@gmail.com wrote: I'd like to add some historical background about how the protocol specification came to be in the first place. A bit over three years [1] ago I started an attempt to document the network protocol, by reverse engineering it from the satoshi client. My goal, back then, was to enable like-minded engineers to create alternative clients and move away from the client-monoculture that is still predominant today. It was clear from the beginning that it would merely be a reverse engineering effort, and that it would likely lag a bit behind the changes in the main client. It was meant as a help for engineers that are not well versed in C/C++ to enable them to contribute by creating new clients, but the satoshi client would always be the de-facto standard. With the move from Google Code to the Bitcoin.it wiki somehow this notion of it being a reverse engineering effort was lost and people started assuming that if the behavior of the satoshi client did not match the protocol description it was a bug on the client side. Instead it is because the reverse engineering of the protocol is incorrect or simply missing some details. Although the protocol description is far more complete than it was back when we started, I still don't feel comfortable giving it the name specification. I still believe that a client monoculture is bad for the system as a whole, because a single bug might bring down the whole network. Giving people the necessary tools to implement new clients brings stability. I do understand the criticism that writing a specification might hinder future development as it restricts the possible changes to the protocol, but isn't this already the case as long as we have legacy versions of the client participating in the network? I would also argue that having a specification allows an application independent review of the protocol to identify possible improvements and bugs. I think the protocol description has an important place in the development of Bitcoin, so much so that we pushed a long time ago to separate protocol version from the client version. I would love to see the protocol specification becoming official part of the bitcoin github repository, which would ideally be maintained alongside the satoshi client to keep it up to date. Regards, Christian Decker [1] https://bitcointalk.org/index.php?topic=231 -- Christian Decker -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.5 with libsecp256k1
Can this be combined with the ideas on deterministic signing to show matching signatures with OpenSSL's implementation?Not sure if that's worth much, since we would just be testing needles in a very large haystack, but better than nothing?On Wed, 09 Oct 2013 20:50:30 -0700, Warren Togami Jr. wtog...@gmail.com wrote:https://github.com/sipa/secp256k1sipa's secp256k1, optimized ecdsa, significantly faster than openssl Today someone in #bitcoin-dev asked for Bitcoin 0.8.5 with sipa's secp256k1. Litecoin has been shipping test builds with secp256k1 for several months now so it was a simple matter to throw together a branch of Bitcoin 0.8.5 with secp256k1. https://github.com/wtogami/bitcoin/commits/btc-0.8.5-secp256k1This branch should theoretically work for Linux, win32 gitian and mac builds. These commits are rather ugly because it was thrown together just to make it build with the old 0.8 makefiles without intent for production code merge. cfields is working on autotoolizing it as one of the prerequisites prior to inclusion into bitcoin master where it will be an option disabled by default. http://193.28.235.60/~warren/bitcoin-0.8.5-secp256k1/Untested win32 gitian build. Build your own Linux or Mac builds if you want to test it. Not recommended for production wallet or mining uses. Warren -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 32.5
I personally like the full-measure of eliminating the CS-PRNG entirely from signing. If the random component is assumed to be untrusted, keeping it in there adds no value, while eschewing the main benefit of deterministic signing (ease of testing, auditing) This just leaves the CS-PRNG at the heart of the security system -- when generating the root master key of an HD wallet. Adding to what Mike said, a single invocation of a CS-PRNG driving all subsequent keys increases the attack value if that one invocation turns out to be weak. By comparison, at least compromised DSA signatures were one-off events which didn't allow theft of funds beyond the one compromised address. Cumulative / rolling entropy collection over time through multiple CS-PRNG invocations, or multiple entropy sources, could serve to recover from an occasionally weak CS-PRNG. I've read claims that this is bad practice because a single low entropy source can take entropy out of the result, but this seems like FUD. If you're using SHA512-HMAC to hash chain a few entropy sources, even return 4; // chosen by random dice roll is not going to help, but it's not going to hurt. The DSA 'repeated-k' basically advertises itself on the block-chain and people were actively scanning for this weakness, whereas a weak key in the BIP32 root might not be as apparent, so exploitation may be more difficult, but also more insidious. Of course this depends on the exact failure mode of the CS-PRNG being used -- I wonder if anyone is searching for BIP32 keys based off of one of the 32k Debian random numbers being used as a master key? Smartphones in particular have lots of sensors which could provide entropy. For example, if you pulled 64 bytes from secure random, you could at least HMAC that with the SHA512 of a picture or a short video sample taken by the user. I'm guessing some people would cringe at this, but it seems to me like it provides some measure of protection to justify the increased code complexity. TL;DR - Really like the idea of minimizing CS-PRNG use whenever possible (deterministic signing) and also would love to learn more best practices for placing less trust in the so called CS-PRNG when we do have to use them. Thanks, Jeremy -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
which could involve proving something to a third party that has not seen
the communication between payer and payee.
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt of the funds
It's easy to prove what public key it was sent to (it's the preimage), but
you can't prove the parent of that public key. You can provide any number of
ParentPubKey * Multiplier that could have been used, so the 3rd party is
unconvinced by a matching ParentPubKey * Multiplier.
However, if you calculated the destination using: PubKeyParent *
HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a
PubKeyParent and Multiplier (or Addend) that produces the destination
address, you've proven the payment is in fact spendable by PubKeyParent, and
they can't deny receipt. Very cool.
Sorry for echoing this back, it took me a little while to work it out, so
I thought I'd write it down. Hope I got it right...
If you give {PubKey, ChainCode} you do get this feature. If you give
{ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to
having plausible deniability.
If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you
could give HMAC(cpar, i) instead of Addend, and then you would get this
feature; a way to 'skip down' a level in the wallet hierarchy, keep the
'chain of custody' so to speak back to the ParentPubKey intact, without
having to disclose the ChainCode. Meh...
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the canonical way
to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual multipliers, if what
you desire is a persistent relationship. If each party dedicates a child-wallet
for receiving coins, and saves a PubKey/ChainCode for sending coins, the two
parties can transaction securely forever without ever exchanging any more
information, and without any address reuse.
I think ideally, the default behavior is that wallets always dedicate a new
child node {PubKey, ChainCode} to each party they transact with. At the
presentation layer, you have a “contact” and each contact has a transaction
history. You can send coins to a contact at any time, and internally the wallet
picks the next address in their sequence. Any funds received on pubkeys from
contact’s sequence are attributed to that contact. The wallet can organize the
contacts, and roll-up the transaction history into ‘ledgers’ and ‘balances’
however they want – it could be based on the underlying BIP32 hierarchy or
perhaps not. The cost of watching large a number of pubkeys, even if you ‘look
ahead’ 100 pubkeys for each contact, is relatively small versus the benefits.
What might be nice is a ‘Contact Request’ protocol, basically the same as a
PaymentRequest but no actual payments are sent, just child wallets created:
message Contact {
optional uint32 contact_version = 1 [default = 1];
optional string pki_type = 2 [default = none];
optional bytes pki_data = 3;
required bytes serialized_contact_details = 4;
optional bytes signature = 5;
}
message ContactDetails {
optional string network = 1 [default = main];
required bytes pubkey = 2;
required bytes chaincode = 3;
optional string memo = 4;
optional string response_url = 5;
}
Alice sends a Contact+ContactDetails to Bob. If Bob accepts, he sends his own
Contact+ContactDetails (without a response_url) back to Alice. Basically just
like adding a contact to your IM contacts.
Alice could send a Contact+ContactDetails to Bob without a response_url, in
which case after accepting the contact, Bob could send funds to Alice, but not
receive funds.
You could probably pack the whole message inside a bitcoin:// URI if you wanted
to.
Thanks,
--Jeremy--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
Hi Alan, “BIP 32 does not prescribe a way to use multiple chains like you described with the convenient type-2 derivation (though we could create a variant that does)” What do you think is missing from BIP32 for this? A wallet creates a child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, and then generally expects transactions to come in starting at /0 and incrementing monotonically. Also, I'm not sure I follow your point about the 128kB hardware wallet -- it's a signing device, so assuming it's even validating output amounts, at worst it cares about the number of inputs to the outputs being spent, but in many cases you're just handing it a sighash and the BIP32 path (/1/54/27/0) to generate the right private key for signing. The hardware wallet is not actually listening on the P2P network and detecting payments, so it's unaffected by dedicating child-nodes to each contact. Consider the benefits of gaining critical mass of support for a technique which [I think] can be used in all cases, and increases security and privacy for everyone. I think there are huge benefits to leaving the age of 'single address generation' behind us... Thanks, --Jeremy -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol
BIP 32 already specifies how to use the first three tree levels: M/i/j/k,
i~wallet, j~Internal/External, k~address. The first level is actually
type-1 derived, and thus we cannot create an arbitrary number of them
without pre-computing them from the offline wallet. So it's not free to
create new wallets unless we redefine how the levels work.
Initially I was thinking that you would share the public key and chain code
from [m/i'/0] so that you can receive payments at [m/i'/0/k], for a unique
value of 'i' for each receive chain.
For the case of generating new receive chains from a *watch-only* wallet, as
you say, the options are to either keep a cache of PubKey/ChainCode for
unused [m/i'] or simply increment 'j' past 1 for an existing [m/i'/j] -- the
concept of 'internal/'external' and change addresses at Depth=2 don't make
sense for handing out receive chains to lots of people anyway, and certainly
BIP32 doesn't *require* 0 = j = 1. So I think incrementing 'j' is the way
to go here...
The default layout of BIP32 does NOT mean that implementations should not
check for transactions with j 1. That would be a useless constraint and
obviously self-limiting. It might be helpful to add to the 'Compatibility'
section some minimum expectations about how a wallet should be 'probed' when
imported. If you don't feel completely free to monotonically increment 'j'
to your hearts content to achieve major usability benefits, then I say BIP32
could use some clarifying.
BTW - the spec calls for addition not multiplication now, so we should call
it the 'Addend' not the 'Multiplier' :-)
Do these extra wallet chains behave as different wallets, or sub-wallets?
They could, but they certainly don't need to! A single-wallet
implementation treats this merely as an address-generation algorithm, and
does not expose any hierarchy to the user interface. The user just
“magically” gets the ability to send multiple payments to their contacts
without immediately sacrificing their privacy
(http://www.wired.com/wiredenterprise/2013/06/bitcoin_retai/). Everything
goes into the same ledger, balance, coin pool, etc. Most of the code base is
unaware BIP32 is even in use.
While it is *possible* to support separate ledgers, balances, etc. it is
certainly not required, and you get all the benefits either way.
I think, since your proposal generates and receives payments into
BIP32-style addresses, we both need similar underlying wallet code. The only
difference is that you are passing the Kpar for [m/i'/0/k] and the *result*
of CKD'((Kpar, cpar), k), and instead I proposed passing Kpar and cpar, and
leaving 'k' out of it, letting the receive choose 'k'.
For instance, maybe there's a benefit to using the same parent pubkey
across multiple services, as a form of identity. If I don't want that, I
use your method. If I do want that, I use my method.
I think it's a interesting idea using static public keys as a means for
persistent identity and hence security from MitM. If you want a shared
public key across multiple services we could just combine both ideas and get
all the benefits, by making the data structure { ParentPubKey, Addend,
ChainCode }:
ParentPubKey: Public key of m/i' -- 33 bytes
Addend: I[L]*G from CDK'(m/i', j) -- 33 bytes
ChainCode: I[R] from CDK'(m/i', j) -- 32 bytes
All that remains secret is the ChainCode from [m/i'] -- and of course the
private keys. The ParentPubKey is a common value across multiple services,
corresponding to user's identity rooted in [m/i']. Each service gets their
own 'j'. ParentPubKey + Addend gives you the PubKey of [m/i'/j]. With the
ChainCode, the receiver then can generate [m/i'/j/k] for monotonically
increasing 'k'. Again, from the user perspective all transactions under
[m/i'] can be presented in a single ledger, or not.
Anyway, fundamentally my feedback is if you are designing for persistent
long-term relationships, you could build in a mechanism for generating
address chains so you don't need any further communication after the initial
exchange, and it need not complicate the wallet.
Thanks,
--Jeremy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
1) The risk that the merchant's web server will be compromised and the attacker will redirect refunds 2) The risk that the merchant will miss payments because they miss a POST to the payment_url (maybe the customer's machine crashes during the HTTPS handshake) If payments are a lot more common than refunds, then (2) will outweigh (1). I think that's oversimplifying. (1) is theft, (2) is payment processing. Reliable payment processing with refund handling is not simple nor free, but it should be secure. The cost of (2) depends primarily on the failure rate, which we can only guess at this point, and secondarily on how much manual intervention is required to recover. (2) is perhaps more of a problem if wallets broadcast before POST. It's trading one failure mode (funds sent but not claimed) for another (coins marked as spent but not). Either way, you fix it by just retrying the POST. But only with Transmit-After-ACK can the payer's wallet detect the failure automatically, and even recover automatically (simply unlock the outputs, or to be sure, spend them back to self). Since merchants get to choose whether to have a POST url, they get to decide if the cost of keeping their server up is worth it. I think eventually there are enough benefits to Transmit-After-ACK that it will become a supported use case. Thanks Mike for explaining the threat. [Aside] I was reading Peter's fidelitybond writeup for his idea on contract value accounting, and he points to Stephan's post from last September on payer-encoded metadata ( https://bitcointalk.org/index.php?topic=108423.msg1178438#msg1178438) which Timo applies here. As a relative newcomer, this is what I am loving most about Bitcoin. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
It's neat to use the payment address as an implicit signature by hashing something and multiplying it into the payee's pubKey. One downside is that it complicates the merchant's wallet. In this case the payment is going to a pseudo-random address which the merchant will have to explicitly add to their wallet, complicating backups, etc. The other challenge is how to handle an error when you POST to the payment_url. In the original spec, the payer would only broadcast the transaction themselves if there wasn't a payment_url. In the current version it looks like the payer will broadcast the transaction(s) either way. I only saw some of the discussions around this, but I think part of the problem is what state do you put the payer's wallet into if you POST a Payment and don't get a PaymentAck? If the payer always broadcasts the transaction, then wallet state becomes obvious. With your proposal you would not want the payer to broadcast the transaction without a PaymentAck, since you need the merchant to acknowledge they know where to look for the payment. Backing up a step, I'm not sure what the threat model is for signing the refund address? The same process that's signing the transaction is doing an HTTPS POST with the refund address. If an attacker can defeat that, then they can just redirect the payment in the first place. The only benefit I can think of is the payer can prove what refund address they specified with the payment. Wouldn't it be easier to just get the merchant to sign the PaymentAck? Technically they already are signing it, but a TLS stream probably isn't the most convenient way to capture that. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cold Signing Payment Requests
There are definitely ways to keep the pay-to address secure even if the web server is compromised, just perhaps not perfectly clean standard X.509 ways under the current ecosystem which would be easier for everyone to agree on. - If a more trusted cert is an EV end cert, and a less trusted is a DV end cert (not chained off the EV) then it's easy for the wallet to distinguish between the two, and they are both valid certs. EV signs pubKey offline, DV used hot on the web server. - If the more trusted cert is an EV or DV end cert, and the less trusted cert is chained off that end cert, it's technically 'invalid' so again its obvious which one is more/less trusted, but it's easier for an attacker to get their own DV end cert for your domain. - The third way is getting the pubKey into the cert attributes, such as encoding the pubKey, or a fingerprint of the pubKey, as a Subject Alternate Name, so the attacker would need to get their own cert to change the address, meaning it's not as critical if your cert key is stolen. On the wallet side, it comes down to additional validation code paths which get triggered by some detection logic. For example, if you pass PubKey and InvoiceID in the Payment Request, the wallet needs to know if it should check for a Subject Alternate Name in the cert for a fingerprint of the PubKey, how the fingerprint is calculated, and then verify the Address is indeed PubKey * InvoiceID. I think falsely rejecting a legacy Payment Request would get the extra validation code path commented out pretty quickly. I really like Mike Hearn's idea of 'You have paid this recipient 4 times' but also agree completely on the crying wolf due to expiration or revocation. At least such a message could be based on the domain name only, to try to prevent phishing with similar domain names, then there's no expiration issue. Slightly more restrictive would be domain + CA, again not considering expiration, but pinning the pay count to the CA seems to have little downside and makes it harder for an attacker to get their own cert for your domain if you choose your CA 'wisely'. I assume the ship has sailed on v1, but if we can get consensus on how we want this to work in the near-term, we can start prototyping it and maybe get this available sooner than later. In any case we should be confirm v1 doesn't do anything to prevent this from working in a clean, extensible manor, which I think means prototyping it and seeing the new Payment Request is handled transparently by v1 code. Right now I'm leaning towards writing a prototype using a single cert with a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey and InvoiceID in the Payment Request. Gavin, would the best way to work on this be to just fork your code on Github? Thanks, --Jeremy -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Cold Signing Payment Requests
Payment Protocol uses x509 certs to sign a Payment Request. This
allows wallets to display meta-data from the cert to the payer instead
of the address, which should make it easier to verify where money is
being sent, and make it harder for an attacker to change the address
displayed to a user so that coins are not sent to the wrong place.
The difficulty is that Payment Requests must be generated live, and
therefore the key used to sign those requests must also be live,
exposing the key to theft similar to a hot wallet. Steal the key,
forge payment requests, and the payer sees a 'green box' but the coins
go to the attacker. The question... is there a way to sign something
once, with a key kept offline, which verifies the address in the
Payment Request belongs to the payee?
1) Given a 'parent' cert which is kept offline, and a child
certificate of 'parent' which is kept hot on the payment server.
2) Given a public key and chain code { pubKey, code } under BIP32 we
generate child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.
3) If we sign Kpar with the parent cert's key offline, we can sign the
remaining less critical data (address, I[0:32], amount, description,
etc.) with the child cert's key.
4) The payer verifies Kpar, and verifies the address by calculating
Hash160(Kpar * I[0:32])
In fact, there's no requirement to use BIP32 to calculate I[0:32], it
could also just be randomly generated.
Any I[0:32] included in the Payment Request, even if it is tampered
with, will correspond to an address for which the payee can calculate
the corresponding private key.
So the idea is your 'most trusted' cert would be used offline only to
sign a Kpar once, and a 'less trusted' cert would be used to sign the
other stuff, like 'amount', 'description', 'merchant-data', and the
'I[0:32]' as well.
I'm not an expert on x509, but I imagine the trouble is, how does the
payer know which cert is which? I was originally thinking the parent
cert would be an intermediate CA cert used to sign the child cert, but
I guess good look getting one of those, even with a name constraint,
from a Root CA. I'm not sure if you can do better than just a
'convention' such as one is an EV cert and one is not. Perhaps the
less trusted cert is actually self-signed using the EV cert, but that
requires special validation, since its no longer a standard
certificate chain. I would love to hear a better idea.
Any comments if this is something worth pursuing? I think there are
definitely benefits if merchants can keep the key signing the address
offline.
Thanks,--Jeremy
--
Try New Relic Now We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
I was discussing this with petertodd a couple days ago and we were thinking the sequence I sent yesterday was usable today. I tried getting it to work on test-net but the final transaction closing the channel was not being accepted into the mempool beacause ERROR: CTxMemPool::accept() : inputs already spent But I was talking with sipa and gmaxwell on IRC about it, and sipa reminded me; Test-Net implements IsStandard() to allow the non-final refund TX into the mempool, but then doesn't allow it to be replaced, Main-Net implements IsStandard() to *reject* non-final transactions in the first place. Therefore, this actually will work on Main-Net today, since the refund TX won't even be allowed into the mempool until it's final, the AP is free to sign and broadcast its final TX without any replacement. Of course, if the AP waits too long, the user can get their Refund into the mempool and the AP's [higher seq] version will be locked out. This may be a case where Test-Net is in a bad state, by allowing non-final TXs into the pool, but not allowing replacement, you get an intermediate state which neither matches Main-Net behavior, nor implements behavior which would ever be deployed to Main-Net as-is. The current Main-Net behavior is actually very well suited for this application. Any application that can be reduced to two instances of a Tx, namely one non-final, and one final which is updated internally between the parties, works very well under the current Main-Net rules. If you set the nLockTime of the refund to be several days after the scheduled closing time of the channel, it would be quite challenging to get the Refund TX into the blockchain *despite* a final broadcast TX from the AP. Since the vast majority of Main-Net won't even accept it, the attacker would have to distribute the TX to any miner who could include the AP's transaction in a block between now and when the refund becomes final, and convince them all to not include the perfectly valid, fees paid, final, nSeq=MAX, nLockTime=0 transaction from the AP. Demonstrating that level of coordination would act substantially against the best interests of the miners, to say the least. This proposal still suffers from any malleability weakness, where the user's refund could be invalidated by a miner changing the TxID of TX1. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anti DoS for tx replacement
I’m not sure I followed John’s proposal fully, why would a user sign TX1 committing funds to the MULTISIG they may never get back? I also don’t see the problem with getting a signed TX2 back from the AP before releasing TX1... see the sequence below. But more importantly, we only need exactly one replacement, so for starters we could anti-DoS by allowing only nSequence of 0 or MAX. If this was enabled on test-net, I would be including a link to transactions that implement the following proposal. At the moment, the best I can do is unit test and generate the rawtransaction output at each step – you can find source code and test output here: https://gist.github.com/jspilman/5424310 The initial funding transaction and time-locked refund is pretty annoying to setup, if you want to support the general case of coins from arbitrarily sized inputs. You will have: - 1 or more inputs from the user, 0 or 1 change outputs - 0 or more inputs from the AP, 0 or 1 change outputs - 1 output to ‘2 PK1 PK2 2 CHECKMULTISIG’ This precludes using SIGHASH_SINGLE except for the special cases where inputs are perfectly sized (i.e. they are created in a prior step). 0. User and AP negotiate how much to escrow, who pays the fees, and how far in the future nLockTime will be set (how long user’s funds will be tied if AP doesn’t close the channel) 1. User creates an unsigned TX1 with 1 or more inputs from user’s ‘listunspent’, change going back to user (if any), and a single output of ‘FundAmount’ with scriptPubKey of ‘2 PK1 OP_0 CHECKMULTISIG’, and sends to the AP 2. AP adds to TX1; their inputs (if any), their change (if any), replaces OP_0 in the scriptPubKey with a PK they control, and signs SIGHASH_ALL, and returns TX1 to User. 3. User verifies TX1 is as agreed, and signs it SIGHASH_ALL, but keeps it to himself. User, having completed TX1, knows its TxID and can now create TX2-Locked spending TX1 back to themselves. User sets nLockTime to the agreed point, signs SIGHASH_ALL, and sends TX2-Locked to AP. 4. AP verifies TX2-Locked and adds their signature, and returns TX2-Locked to User. User can now broadcast TX1 and TX2-Locked. 5. At each payment milestone, user creates TX2-Final; TX1 as input, final nSequence, no lock time, with a single output going back to to the user, and an amount equal to the remaining balance of the channel. User signs with SIGHASH_SINGLE and sends to the AP. 6. AP can add an output to TX2-Final sending their portion of the coins where ever they want, sign it SIGHASH_ALL, and broadcast it at any point, closing the channel. AP must broadcast TX2-Final before nLockTime, but has no guarantee the user hasn’t offered a bribe for miners by spending TX2-Locked with a large fee, e.g. a pissed off user spends TX2-Locked entirely to fees just to see if they can convince miners to wait for it. The alternative to the TX2-Locked is a 3rd party in the MULTISIG who is trusted to close the channel at the request of either party, based on the latest TX2-Final which was sent by the user. In this case there is no TX2-Locked, only a single boardcast version of TX2-Final, and you do not need transaction replacement at all. Thanks, --Jeremy -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
