Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-19 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-20 Thread Jeremy Spilman
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

[Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-29 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-30 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-20 Thread Jeremy Spilman
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

Re: [Bitcoin-development] BIP 32.5

2013-08-16 Thread Jeremy Spilman
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

Re: [Bitcoin-development] 0.8.5 with libsecp256k1

2013-10-09 Thread Jeremy Spilman
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.

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-24 Thread Jeremy Spilman
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 wrote: I'd like to add some historical background about how the protocol specification came to be in the first place. A bit

Re: [Bitcoin-development] Making fee estimation better

2013-10-25 Thread Jeremy Spilman
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

Re: [Bitcoin-development] BIP proposal - patch to raise selfish mining threshold.

2013-11-05 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Floating fees and SPV clients

2013-12-03 Thread Jeremy Spilman
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.

Re: [Bitcoin-development] Dedicated server for, your thoughts?

2013-12-08 Thread Jeremy Spilman
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

[Bitcoin-development] Peer Discovery and Overlay

2013-12-24 Thread Jeremy Spilman
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

[Bitcoin-development] Access to Mempool

2013-12-27 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Dedicated server for, your thoughts?

2013-12-31 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Dedicated server for, your thoughts?

2014-01-01 Thread Jeremy Spilman
So I looked into gitian, the first thing I noticed was the hashes that people were signing, for example: don't match the hash of the file 'bitcoin-0.8.6-win32-setup.exe' actually hosted by

Re: [Bitcoin-development] Privacy and blockchain data

2014-01-07 Thread Jeremy Spilman
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.

Re: [Bitcoin-development] Stealth Addresses

2014-01-08 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Stealth Addresses

2014-01-12 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Stealth Payments - Sample Code / Proof of Concept

2014-01-13 Thread Jeremy Spilman
On Mon, 13 Jan 2014 03:18:28 -0800, Mike Hearn wrote:Cool!On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman wrote: I spent 1BTC on TestNet to a stealth address... TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c... but can you redeem

Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Jeremy Spilman
On Tue, 14 Jan 2014 06:19:08 -0800, Peter Todd 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Jeremy Spilman
On Tue, 14 Jan 2014 13:51:06 -0800, Adam Back 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-15 Thread Jeremy Spilman
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

Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)

2014-01-15 Thread Jeremy Spilman
On Wed, 15 Jan 2014 15:09:01 -0800, Adam Back 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-16 Thread Jeremy Spilman
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, 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

Re: [Bitcoin-development] Stealth Addresses

2014-01-18 Thread Jeremy Spilman
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner 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

Re: [Bitcoin-development] unlinakble static address? spv-privacy (Re: Stealth Addresses)

2014-01-20 Thread Jeremy Spilman
On Wed, 15 Jan 2014 17:32:31 -0800, Gregory Maxwell 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

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-01-27 Thread Jeremy Spilman
On Jan 27, 2014, at 9:39 AM, Andreas Schildbach 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

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Jeremy Spilman
Please note, responding to Pieter and Chuck concurrently. On Thu, 30 Jan 2014 07:16:54 -0800, Pieter Wuille 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

Re: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)

2014-02-02 Thread Jeremy Spilman
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

Re: [Bitcoin-development] bitcoinj 0.11 released, with p2sh, bip39 and payment protocol support

2014-02-04 Thread Jeremy Spilman
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

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-19 Thread Jeremy Spilman
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

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-24 Thread Jeremy Spilman
On Mon, 24 Feb 2014 09:10:26 -0800, Jeff Garzik wrote: This PR reduces the size to 40 bytes: 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

Re: [Bitcoin-development] Fee drop

2014-02-25 Thread Jeremy Spilman
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

[Bitcoin-development] Positive and negative feedback on certificate validation errors

2014-02-28 Thread Jeremy Spilman
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

Re: [Bitcoin-development] Positive and negative feedback on certificate validation errors

2014-02-28 Thread Jeremy Spilman
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir 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

[Bitcoin-development] Payment Protocol Hash Comments

2014-03-01 Thread Jeremy Spilman
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

Re: [Bitcoin-development] BIP70 extension to allow for identity delegation

2014-03-02 Thread Jeremy Spilman
On Fri, 28 Feb 2014 03:46:49 -0800, Mike Hearn 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

Re: [Bitcoin-development] Bitcoin address TTL key expiration?

2014-07-15 Thread Jeremy Spilman
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

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-27 Thread Jeremy Spilman
On Mar 27, 2015, at 8:16 AM, Matt Whitlock 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

Re: [Bitcoin-development] network disruption as a service and proof of local storage

2015-03-24 Thread Jeremy Spilman
On Mon, 16 Mar 2015 09:29:03 -0700, Sergio Lerner wrote: I proposed a (what I think) is better protocol for Proof of Storage that I call Proof of Local storage here Thanks so much for