The original Bloom filtering spec did not make this feature optional for
the same reason gzip isn't an optional part of the PNG specification. I see
no reason to revisit that. It's definitely not the case that making every
possible feature optional is smart design, often it's the opposite.
If in f
nd bandwidth
> matters.
>
> Warren
>
>
> On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn wrote:
>
>> That change was made in response to user complaints. Heck we get
>> complaints about battery life and bandwidth impact even with Bloom
>> filtering. We can
Oops, hit send too early.
Besides, prioritisation isn't very hard. Nodes can just hand clients a
> signed timestamp which they remember. When re-connecting, the signed
> timestamp is handed back to the node and it gives priority to those with
> old timestamps. No state is required on the node side
On Fri, Aug 16, 2013 at 4:59 PM, Peter Todd wrote:
> UPNP seems to work well for the reference client. What's the situation
> there on Android?
>
Not sure - it could be investigated. I think UPNP is an entirely
userspace-implementable protocol, so in theory it could be done by a
userspace librar
That change was made in response to user complaints. Heck we get complaints
about battery life and bandwidth impact even with Bloom filtering. We can't
just randomly start using peoples bandwidth for relaying blocks, especially
as I guess most SPV nodes are behind NAT.
If Gavin is right and the fu
ay the block size limit increase for another year or
> two?* This patch alone enables that.
>
>
>
> On Fri, Aug 16, 2013 at 2:24 AM, Mike Hearn wrote:
>
>> The only other thing I'd like to see there is the start of a new anti-DoS
>> framework. I think once t
'd be the
whitepapers. At the moment we still have plenty of headroom in block sizes,
even post April. It can probably be safely delayed for a while.
On Fri, Aug 16, 2013 at 2:11 PM, Mike Hearn wrote:
> Cool. Maybe it's time for another development update on the foundation
> blog?
Cool. Maybe it's time for another development update on the foundation blog?
On Fri, Aug 16, 2013 at 3:00 AM, Gavin Andresen wrote:
> Mike asked what non-0.9 code I'm working on; the three things on the top
> of my list are:
>
> 1) Smarter fee handling on the client side, instead of hard-coded f
I filed a bug in the bitcoinj tracker for this a few days ago referencing
rfc 6967, but that RFC is very complicated and I'm not sure it's really
necessary to go that far. H(sighash||key) is easy to implement and I feel I
understand it better.
In our case it wouldn't have helped anyway - if anythi
> Our plan is to add support for that into v1 firmware, but it also depends
> on readiness of surrounding infrastructure; mainly if there'll be support
> for payment protocol in multibit in the time of v1 release (I suppose that
> the Multibit will be the first wallet compatible with Trezor AND
>
On Thu, Aug 15, 2013 at 10:22 AM, slush wrote:
> We're planning to support payment protocol in Trezor as well, if it
> counts. I think it's a missing piece in absolute security of hardware
> wallets.
>
Yup, that's always been the plan :-)
Any idea how much work it is, and would it be a v1 featu
Sounds awesome!
Pieter told me at lunch that headers first cut sync time to 45 minutes for
him, which is another amazing improvement from the master of optimisations.
Pieter, Matt and I also agreed that for maximum impact we should really try
to ship payment protocol support in at least two clien
Hello,
I'm pleased to announce version 0.10 of bitcoinj, a Java library for
writing Bitcoin applications. BitcoinJ has been used to create everything
from end-user wallet apps to network crawlers to SatoshiDice.
To learn how to obtain bitcoinj 0.10, please see the following page:
https://code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hello,
I hope you are having a pleasant weekend. A few days ago we learned
that the Android implementation of the Java SecureRandom class
contains multiple severe vulnerabilities. As a result all private keys
generated on Android phones/tablets are
he payment protocol itself. I
> didn't feel like I'd have much to contribute (besides requesting a feature
> I know isn't there). I was planning to wait until it was complete before
> fully grokking and implementing it in Armory.
>
>
>
> On 08/09/2013 03:58 PM,
ng
> Alice money, then a year later Bob will send money automatically to Alice
> not realizing that the wallet was lost, retired or compromised. It's not
> that Bob can't ask for a new address, it's that if the interface says "Send
> Money to Alice", that looks leg
ar to native apps (they get their own windows, run offline,
etc).
But these aren't standard APIs. They're all Chrome extensions. I doubt
HTML5 will support USB access anytime soon, for instance, but packaged apps
do.
On Fri, Aug 9, 2013 at 2:10 PM, Mike Hearn wrote:
> Cod
solution to the concerns you expressed?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Aug 9, 2013, at 1:48 PM, Mike Hearn wrote:
>
> > JavaScript is turing complete so of course it can be done. The real
> question you're asking is, can it b
>
> Bitcoin sought to reduce dependence on trusted third parties, where as,
> persona is increasing the reach of trusted third parties. The keys and
> passwords are stored on mozilla's servers, sometimes on your email
> providers. Persona, is however, a progression and will hopefully improve
> it
JavaScript is turing complete so of course it can be done. The real
question you're asking is, can it be done in a web app? I think the answer
is I think "no" because web apps aren't allowed to make raw TCP socket
connections.
Now there may be a way around that by using browser-specific things lik
This is just me making notes for myself, I'm not seriously suggesting this
be implemented any time soon.
Mozilla Persona is an infrastructure for web based single sign on. It works
by having email providers sign temporary certificates for their users,
whose browsers then sign server-provided chall
Agreed, this looks good to me.
--
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.
D
> My concerns here are:
> * Making sure wallet applications can function without supporting the
> P2P protocol (which drops a huge implementation overhead for simple -
> perhaps hardware-based - wallets)
How would such wallets get transactions into their wallet in the first
place?
The P2P protoc
> I'd like to hear from other wallet implementors. Do you have a notion
> of 'locked inputs' ? The tricky bit in constructing a transaction but
> not broadcasting it right away is the inputs must be locked, so
> they're not accidentally double-spent.
>
bitcoinj separates the concept of committing
As you're Mac specific you could just use a modified Sparkle or something
like that. Even if you want to use a stock Sparkle, I have some code that
does threshold RSA. My intention was to use it for the Android wallet but I
never found the time. I can send you a copy if you want. But it's easier
an
> They have poor space/bandwidth usage properties, which is one reason
> why Bitcoin doesn't use them today, but as far as I know the same is
> so for all post-QC schemes.
>
I believe post-QC schemes based on Regev's LWE assumption are getting
competitive with more traditional schemes. A paper fro
Sorry, I just noticed that this thread was CCd to the announce list not the
development list (why is it open access?)
It's offtopic anyway. Let's continue this discussion in private if anyone
wants to.
On Wed, Jul 31, 2013 at 5:53 PM, Mike Hearn wrote:
>
> The reason why TPM f
"Support" for a TPM is a rather tricky thing.
By itself the TPM is independent of any CPU. However, it's also not very
useful (though for Pond's use case, it works).
The TPM gets much more useful when it's integrated with features on the
motherboard, BIOS, CPU, northbridge, IOMMU etc. Then you ha
Woo, huzzah :-)
Now the BIP draft is available and we know it all hangs together, I'm
hoping to (re)start implementation work in bitcoinj in the next month or
two. I'm currently trying to figure out which is more important,
deterministic wallets or payment protocol, but I think right now the
payme
TPMs have come as standard with nearly all computers (except Macs, doh) for
a long time. They certainly don't cost $100. More like a few dollars at
most. That's why they're so slow.
On Tue, Jul 30, 2013 at 10:43 PM, grarpamp wrote:
> On Tue, Jul 30, 2013 at 8:12 AM, Mike Hea
Various ideas are possible:
* Use the Tor SOCKS proxy in such a way that it creates a guaranteed
independent circuit to a different exit node each time you connect. This
gets you back to the slightly stronger clearnet heuristic of "if I saw a
bunch of peers announce my tx, then it's probably valid
ar with TPM
> chips?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
>
> On Jul 30, 2013, at 10:40 AM, Mike Hearn wrote:
>
> > As a testament to the seriousness with which Pond takes forward
> security, it can use the NVRAM in a TPM chip to reliably destr
For people who are interested in such technologies, I recommend looking at
Pond:
https://pond.imperialviolet.org/
It is written by Adam Langley, so it comes with some serious credentials
behind it. It provides asynchronous email-like messaging that's forward
secure, resistant to traffic analysis
Yeah, if anyone wants to make the letter more digestable please do propose
an alternative, although by this point it's probably not worth it as people
have already signed.
FWIW, Gregory is right that my original draft was much more brusque. The
pain in the packaging relationship travels both ways.
o not fiddle with the content, which they did not
do.
If you'd like to have your name on it, let me know or post here and I'll
add it.
On Tue, Jul 23, 2013 at 10:14 PM, Gregory Maxwell wrote:
> On Tue, Jul 23, 2013 at 1:01 PM, Mike Hearn wrote:
> > Hi,
> >
> >
Hi,
Some of us have put together an open letter to the Linux packaging
community, outlining why Bitcoin is different to other programs and asking
them to not patch or modify the upstream sources.
Please consider signing it if you agree (I think the wording by now is
fine, so don't edit the conten
This isn't usable for SPV wallets unless it has a birthday in it. Otherwise
you either need to scan the entire chain (slow) or find a fully indexed
copy of the block chain (expensive, more centralised). Just add a UNIX time
as an extra 4 bytes, or if you want to save a few characters then use a
uin
As an FYI, I've sent Wendell and co some example code for how to use CPPJVM
to use bitcoinj from native code. A rather rough Hello World app looks like
this:
https://github.com/mikehearn/cppjvm/blob/master/mytest/bcj-hello-world.cpp
So, fairly C++ like.
Further discussion of this should take pla
x27;re going to
start only storing relevant outputs in the wallet and doing other things to
try and save memory. Some people managed to get themselves wallets that
don't actually fit in ram :(
On 21 Jul 2013 17:55, "Pieter Wuille" wrote:
> On Tue, Jul 16, 2013 at 12:59:56PM +02
> SPV clients behaving normally are highly abusive: they use up maximum
> node resources with minimum cost to themselves.
>
This must be a new use of the word "abuse" I haven't come across before :)
At any rate, some of these assumptions are incorrect. Botnets of
compromised web servers are quite
> The 90 minutes is not - the blockchain has grown quite a lot since last
> year, and as for the 3.5 speed, I havn't tested it since Pieter's
> ultraprune - libcoin also has something similar to ultraprune, done
> directly in the sqlite database backend, but I should run a head to head
> again - co
Is that still accurate Michael?
On Wed, Jul 17, 2013 at 4:58 PM, Wendell wrote:
> "The libcoin/bitcoind client downloads the entire block chain 3.5 times
> faster than the bitcoin/bitcoind client. This is less than 90 minutes on a
> modern laptop!"
>
> Good lord Michael, I wish we had known abo
onitor it stays connected for as long as the screen is on and the app
> in the foreground (= resumed state).
>
>
> On 07/17/2013 02:29 PM, Mike Hearn wrote:
>
> > Partial UTXO sets is a neat idea. Unfortunately my intuition is that
> > many SPV wallets only remain open for &l
On Wed, Jul 17, 2013 at 2:37 PM, Tamas Blummer wrote:
> A majority coalition of miner (pool operator) might even decide to change
> block reward
> rules if the rest of the network only verifies POW.
>
Which is why it's still vital that any "important" node in the economy uses
full validation.
A
wrote:
> > Hello everyone,
> >
> > In the previous thread, I expressed interest in seeing an SPV bitcoind,
> further stating that I would fund such work. Mike Hearn followed up with
> some of Satoshi's old code for this, which is now quite broken. The offer
> and
ote:
> Hello everyone,
>
> In the previous thread, I expressed interest in seeing an SPV bitcoind,
> further stating that I would fund such work. Mike Hearn followed up with
> some of Satoshi's old code for this, which is now quite broken. The offer
> and interest o
Let's re-add the list as this is a topic of general interest.
On Tue, Jul 16, 2013 at 11:36 AM, Jonas Schnelli wrote:
> What do you think about extending the BitcoinKit.framework (based on
> bitcoind) so that the kit could handle the very basic SPV concept
> (getHeaders aka fast catchup, wallet-
> Clear. Your right. C++ would give us more flexibility (other platforms)
> and also android compatibility (through NDK).
>
I'm a bit confused I'm afraid. bitcoinj already runs SPV wallets on Android
on top of Dalvik. In fact that's what it's designed for. The NDK is not
necessary to work with Bit
l 15, 2013 at 4:39 PM, Wendell wrote:
>
>> Hi Mike,
>>
>> You are absolutely right about the synchronize time, it's one of our main
>> frustration points right now and we clearly won't deliver the kind of user
>> experience we want, without fixing
ling. We
> discounted Java simply because an OS X JVM is no longer guaranteed, but
> otherwise bitcoinj is ideal for our purposes. How can we assist or
> otherwise accelerate such an effort?
>
> -w
>
> On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
>
> > That's gr
That's great! I'm all for more wallets, especially user friendly UIs.
However being based on bitcoind means it will take a very long time to
synchronize for new users. We know a lot of users drop out. The best fix
for this is SPV mode. Do you have any plans in this direction?
So far, the only SPV
That's good to know. Still, at the moment we'd need to dramatically
increase the download size and increase Bitcoin usage by 10x to hit our
limits. It'd be a good problem to have.
On Tue, Jul 9, 2013 at 5:51 PM, Johnathan Corgan
wrote:
> On 07/09/2013 08:32 AM, Nick Simpson wrote:
>
> > What abo
That's true - we could serve new users off our own servers and auto updates
off SF.net mirrors, potentially.
On Tue, Jul 9, 2013 at 4:57 PM, Daniel F wrote:
> on 07/09/2013 10:28 AM Mike Hearn said the following:
> > SourceForge has a horrible UI and blocks some countries. I
SourceForge has a horrible UI and blocks some countries. It also exposes us
to a large and potentially hackable mirror network. Whilst we're not
bandwidth constrained on our own servers, let's try and keep using them.
On Tue, Jul 9, 2013 at 4:06 PM, Jeff Garzik wrote:
> On Tue, Jul 9, 2013 at 1
ne it's better than nothing.
On Tue, Jul 9, 2013 at 1:04 PM, Mike Hearn wrote:
> How many downloads/day do we see currently? I think you said it's on the
> order of a few thousand, so nowhere near 30k I'd guess. Anyway I can mirror
> it if we need to.
>
> The Ja
6s are correct
> for instance. This would increase the maximum number of
> downloads we could cope with.
>
>
> On Tue, Jul 9, 2013, at 11:36 AM, Mike Hearn wrote:
> > Modern Java versions let you bundle the app with a stripped down JVM. I
> > don't know if Jim
s possible.
> > + Failing that people are directed first to
> bitcoin.stackchange.com <http://bitcoin.stackchange.com>
> >(I have a notification set up for the 'multibit' keyword.
> > + Then finally users are directed to the github is
Sounds like we have consensus, Saivann, shall we do it?
I'm also going to ask Theymos again to relax the newbie restrictions
for the alt client forums. It's probably too hard to get support at
the moment and "email jim" doesn't scale at all.
On Fri, Jun 28, 2013 at 4:24 PM, Gavin Andresen wrote:
I suspect what you saw is mining nodes restarting and clearing their
mempools out rather than an explicit policy of replace by fee.
On Fri, Jun 28, 2013 at 12:09 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Fri, Jun 28, 2013 at 9:05 AM, Mike
> Arguments in favor of retaining Bitcoin-Qt/bitcoind default:
> * More field experience, code review and testing on desktop than others
I'm hoping that if we start promoting alternative wallets their dev
communities will get larger. Most bitcoinj code is peer reviewed, but
not to the same extent
> There were a number of issues with it at the time, in
> particular the frequent deadlocks— though Mike was saying that those
> should be fixed.
Yes. There were a number of lock cycles that didn't cause issues so
much when traffic was lower and as Bitcoin got more popular it became
a critical pro
Indeed, and for a higher level answer, see here:
https://en.bitcoin.it/wiki/Contracts
On Fri, Jun 21, 2013 at 6:03 AM, Patrick Strateman
wrote:
> It's well answered by this stack exchange question.
>
> http://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence
>
>
> On 06/20/2013 0
it makes no assumptions based on that
>> which is a mistake (new clients can broadcast older version messages that
>> don't have all the fields required). Probably the software should penalise
>> hosts which do that.
>>
>> What's the big deal to update the prot
bly the software should penalise
> hosts which do that.
>
> What's the big deal to update the protocol version number from 70001 to
> 70002? It's not like we'll run out of integers. The field has now gone from
> optional to required now anyway - that's a behav
#x27;t handle it need to fix their code anyway.
So I have a slight preference for keeping things the way they are, it keeps
things flexible for future and costs nothing.
On Thu, Jun 20, 2013 at 11:06 AM, Pieter Wuille wrote:
> On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
&g
flag added in BIPXX is not present.
>
> Your argument is that this complexity is already there so why not preserve
> it. I think eliminating complexity (that has no benefit) strengthens the
> system.
>
> *Tamás Blummer*
> http://bitsofproof.com
> <http://bitsofproof.com/>
Sure but why not do that when there's an actual new field to add? Does
anyone have a proposal for a feature that needs a new version field at the
moment? There's no point changing the protocol now unless there's actually
a new field to add.
Anyway I still don't see why anyone cares about this issu
Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose
ery field change, the protocol version should be upgraded.
>
> Now that fRelayTxes is part of the protocol, the version number should be
> upgraded to reflect this fact.
>
> --
> *From:* Mike Hearn
> *To:* Paul Lyon
> *Cc:* Turkey Breast ; "
in dev community, so let me know if I’m horribly violating
> any mailing list etiquette. 😊
>
> *From:* Mike Hearn
> *Sent:* Wednesday, June 19, 2013 7:43 AM
> *To:* Turkey Breast
> *Cc:* bitcoin-development@lists.sourceforge.net
>
> Bitcoin-Qt on master does sen
icating it should. Nowhere was this
> written. It doesn't help other implementations to have an unclear behaviour
> that depends on some magic from one implementation.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* "bitcoin-development
a 1 byte flag
> needs to be optional anyway.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* Bitcoin Dev
> *Sent:* Tuesday, June 18, 2013 9:48 PM
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always
been variable length. There's nothing inherent in the Bitcoin protocol that
says all messages are fixed length, indeed
I'm pleased to announce the release of bitcoinj 0.9, a Java library for
working with the Bitcoin protocol. Both simplified and full verification
are supported. BitcoinJ has been used to create everything from end-user
wallet apps to network crawlers to SatoshiDice.
To get bitcoinj 0.9, check out o
On Thu, Jun 6, 2013 at 2:19 AM, Peter Vessenes wrote:
> So, this
> http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
> article got posted today, noting that FinCEN thinks irrevocable payments
> are money laundering tools.
>
That's not how I read it, I don't
Bitcoinj already has such chain id's and we use standard Java style reverse
DNS names: org.bitcoin.main, etc. If we want a more global naming system
that seems like a good compromise between uniqueness and readability.
On 20 May 2013 19:45, "Jeff Garzik" wrote:
> On Mon, May 20, 2013 at 7:59 PM,
Indeed, that has been proposed but it's a dumb idea and I'm very sceptical
it will go anywhere. Certainly no decision was made. The arguments for it
are based on some quite faulty thinking about economics. Double spend
notifications have been proposed a long time ago, I believe Matt has
indicated
I'm all for funding of Bitcoin development, but I suggest talking to Gavin
to find out what efforts would be the biggest win right now. I don't see
why separating wallet code from the main Bitcoin process would increase
node count, as the cost of running the node is almost all in keeping up
with tr
Conceptually it sounds a lot like ZeroCoin (not in implementation)?
I'm not really convinced miner cartels that try to exclude transactions are
likely to be a big deal, but such schemes could I suppose be kept in a back
pocket in case one day I'm proven wrong.
On Wed, May 15, 2013 at 6:39 PM, Gr
> I've been thinking about a decentralized way to create an anonymous
> identity
This is the fidelity bond/anonymous passport idea that has been kicked
around in the forums quite a few times. I mentioned it on the tor-talk once
as a solution to the problem that you cannot create Google accounts v
2038 issues only apply to use of signed timestamps, I thought we treat
this field as unsigned? Is it really a big deal?
On Thu, May 9, 2013 at 1:12 PM, Pieter Wuille wrote:
> On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote:
>> Ah, shoot, I just realized we both got missed Pieter's poin
> And even without a PGP WoT connection, if the website had SSL enabled, they
> can trust the binaries its sending to the extent that it is securely
> maintained
Yes, it would be nice to have SSL but that requires finding
alternative file hosting.
> I guess its the least of the concerns but I bel
> Seems like the website redesign managed to hide the signatures pretty
> good. They're in the release announcements in any case, but that
> should be fixed. Even when they were prominently placed, practically
> no one checked them. As a result they are mostly security theater
Security theater in
> You mean scam you with a zero-conf transaction that hasn't actually been
> broadcast?
Yeah. Or just scam you at all. It's hard to imagine an organisation as
a big as a mobile carrier engaging in financial scamming (roaming fees
excepted).
I've said this before, but I think it's worth repeating.
> Speaking of, off-topic for this discussion, but in the future
> node-to-node communicate should be encrypted and signed
Yes, I'd like to do this. The threat isn't really ISPs which are
mostly trustable (the worst they normally do outside of places like
China is dick about with ads), the big thre
> > I've noticed on my Android phone how it often takes quite awhile to find
> > a peer that will actually accept an incoming connection, which isn't
> > surprising really: why should a regular node care about responding to
> > SPV nodes quickly?
I haven't seen that - remote nodes don't have any s
Subject change to reflect that this is off-topic for the old thread.
Eventually, I think it makes sense to move to a system where you get seeds
> from
> a DNS (or other mechanism), connect to one or a few of the results, do a
> getaddr,
> fill your peer IP database with it, and disconnect from the
It's expected to be there, yes.
On Mon, May 6, 2013 at 9:56 AM, Addy Yeow wrote:
> >From https://en.bitcoin.it/wiki/Protocol_specification#version, is the
> relay field (bool/1 byte) required in all version packets coming from
> client with protocol version >= 70001?
>
>
> -
You are welcome to optimise P2P addr broadcasts or develop better bootstrap
mechanisms.
On Sun, May 5, 2013 at 3:12 PM, John Dillon
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Sorry I should have used the word bootstrapping there rather than
> discovery.
> But again I think th
> If you're going to take a step like that, the
> should be rounded off, perhaps to some number of bits, or you'll allow
> DNS caching to be defeated.
>
Don't the seeds already set small times? I'm not sure we want these
responses to be cacheable, otherwise there's a risk of a wall of traffic
sud
> Yes, I like that better than broadcasting the exact height starting at
> which you serve (though I would put that information immediately in the
> version announcement). I don't think we can rely on the addr broadcasting
> mechanism for fast information exchange anyway. One more problem with this
Chrome has whitelisted bitcoin: URIs for web apps, and Firefox it turns out
doesn't use whitelisting at all, so it already works there.
https://chromiumcodereview.appspot.com/14531004
I'm hoping this means web wallet developers won't be put off from
supporting the payment protocol (that risk is t
> 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.
>
It's a real threat, albeit an exotic one. The threat model is a malware
compromised host, with a wallet
That's true. It can be perhaps be represented as "I keep the last N blocks"
and then most likely for any given node the policy doesn't change all that
fast, so if you know the best chain height you can calculate which nodes
have what.
> Disconnecting in case something is requested that isn't serv
I'd imagined that nodes would be able to pick their own ranges to keep
rather than have fixed chosen intervals. "Everything or two weeks" is
rather restrictive - presumably node operators are constrained by physical
disk space, which means the quantity of blocks they would want to keep can
vary wit
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell wrote:
> I am not sure if my replies hit the list. If not, can anyone who sees this
> help?
>
> In the past, I have pre signed (with PGP) large batches of Bitcoin
> addresses for distribution on my server. This way, even in the event of
> compromise,
>
> So I don't see how you can have a payment request signing key that's safer
> than an SSL key. As Jeremy notes, CAs will not issue you intermediate
> certificates. Perhaps if one existed that would do the necessary things for
> a reasonable price you could indeed give yourself an offline interme
>
> > That's a pointless goal to try and solve right now, because the SSL
> > PKI cannot handle compromised web servers and so neither can we (with
> > v1 of the payments spec).
>
> I don't think the OP intended to solve it "right now", i.e. in v1.
>
> He differentiated between "most trusted" and "
> Chaining a custom cert onto the end doesn't work, at least not if your
> "end" is the SSL cert. Chaining it to the SSL cert defeats the OP's
> intention of "cold signing", as the SSL private key is usually kept
> online, therefore can't be used to sign a pubkey that is supposed to
> stay offline.
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).
So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to get
601 - 700 of 877 matches
Mail list logo
