It uses ~no electricity, it's not like mining.
The primary resources it needs are disk space and bandwidth, after an
intensive initial day or two of building the database.
Actually, I wonder if we should start shipping (auditable) pre-baked
databases calculated up to the last checkpoint so
* Sent 456.5 gb data
At my geographic service location (Singapore), this cost about $90 last
month for bandwidth alone.
One of the reasons I initiated the (now stalled) PayFile project was in
anticipation of this problem:
https://github.com/mikehearn/PayFile
This comes up every few months. I think the problem you are trying to solve
is already solved by SSL client certificates, and if you want to help make
them more widespread the programs you need to upgrade are web browsers and
not Bitcoin wallets. There are certainly bits of infrastructure you
On Fri, Apr 4, 2014 at 3:22 PM, Eric Larchevêque ela...@gmail.com wrote:
I see only benefits for the entire ecosystem, and if I'm working on such a
proposition it is because I really need this feature.
Why do you need it? Because you don't want to implement a login system?
Very, very few
What if I do a shared spend/CoinJoin type tx? Now anyone who took part in
the shared tx with me can get into my hotel room too?
Oh, if these seem too abstract, also consider bitbanks. In an ideal world
nobody would outsource running of their Bitcoin wallet, but sadly people
do, so then they
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then
we have a problem :) But regardless, actually like I said, you don't need a
plugin. Browsers do it all already. With the keygen tag they even create
a private key and upload the public part to be signed for you, it's
payments to be made
to the wrong party? Of course-- but that's already true. And that's not
something BIP70 solves (or attempts to solve) either.
(To explain [better than I could] why I feel PKI is a pragmatic solution,
I defer to Mike Hearn 's article:
https://medium.com/bitcoin-security
This proposal will destroy Bitcoin. I would expect nothing less coming from
a Google employee.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
They would just encode the OP_RETURN script into an Output structure. I'm
not sure about the question - you seem to give the answer yourself in the
first paragraph?
--
___
Right - the explanation in the BIP about the board of directors is IMO a
little misleading. The problem is with splitting a private key is that at
some point, *someone* has to get the full private key back and they can
then just remember the private key to undo the system. CHECKMULTISIG avoids
Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If
you have a use for a new type of script it can be added, and people do
upgrade:
http://getaddr.bitnodes.io/dashboard/chart/?days=30
As you can see the 0.9 rollout is going OK. If a new script type had been
made standard for
Ranvier justusranv...@gmail.comwrote:
On 03/29/2014 01:30 PM, Mike Hearn wrote:
They would just encode the OP_RETURN script into an Output structure. I'm
not sure about the question - you seem to give the answer yourself in the
first paragraph?
I guess what I was asking is whether
Modern devices like smartphones and tablets do not have swap files. This
design is chosen to ensure responsive, fluid UI that can avoid blocking on
disk regardless of how much multi-tasking is done, but it creates ripples
that impact everything else.
One implication of this is that on these
I don't want to manage a business relationship with every shop I buy
something from. That's way too much effort. There can certainly be cases
where a more complicated relationship is created by bootstrapping off
BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller
What is too abstract in a contact list ? If the payment comes with a tag
like refund the UI could display as such and if it comes with e.g. VAT then
that.
How is this any different? The tag in this case is the address and the
payment is being delivered by the block chain (direct submission
It is not more effort than an auto remembered call-in phone number. You
delete if you do not care. The difference however is that it would be a
clean protocol for repeated payments in both directions for whatever
reason, where refund is and payment are not special compared to 1st
So I take it BOPShop won't be supporting BIP70 then? :(
On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer ta...@bitsofproof.comwrote:
I have nothing against incremental development. This will however not pick
up until it offers some incremental benefit compared to current payment
processor
Supporting BIP70 by BitPay or BopShop is a cake since it does no more then
they did without it.
I am not in opposition but see no reason to be enthusiastic about it. I
will once the spec goes
further than what was possible before.
So, if e.g. Trezor ships a firmware update that uses BIP70
Yeah. Though there's actually a proposal for recurring payments from the
KillBill folks. I keep bugging BitPay to review it but it seems they're
lagging behind there, so perhaps we should just move ahead with that
candidate extension.
On Fri, Mar 28, 2014 at 3:01 PM, Gavin Andresen
On 28/03/2014 17:59, Andreas Schildbach wrote:
Ok, why don't fix this in the spec for now, by defining a fixed expiry
time. In the EU, most products are covered by a 2 years warranty, so it
seems appropriate to pick 2.5 years (30 months) -- allowing for some
time to ship the product back and
On 26.03.2014, at 21:49, Mike Hearn m...@plan99.net wrote:
Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot
But these cases are the norm, rather than the exception.
Well, you're lucky, you live in Berlin. Most of the payments I make with
Bitcoin are online, to websites. So this will differ between people.
I wonder how critical it is. Let's say you are paying for a meal. In your
head the place
One issue that I have is bandwidth: Electrum (and mycelium) cannot
watch as many addresses as they want, because this will create too
much traffic on the servers. (especially when servers send utxo merkle
proofs for each address, which is not the case yet, but is planned)
This is surprising
By the way, I just noticed that greenaddress.it is creating seeds that have
24 words instead of 12. Does anyone know what's up with that? They claim to
be using BIP32 wallets so I wanted to see if they were using the default
structure and if so, whether bitcoinj was compatible with it (before I
.
On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn m...@plan99.net wrote:
Ah, BIP32 allows for a range of entropy sizes and it so happens that they
picked 256 bits instead of 128 bits.
I'd have thought that there is a right answer for this. 2^128 should not
be brute forceable, and longer sizes have
To be honest, I have not carried out a comprehensive examination of
server performance. What I can see is that Electrum servers are often
slowed down when a wallet with a large number (thousands) of addresses
shows up, and this is caused by disk seeks (especially on my slow VPS).
Yes that
(the number of days since the genesis
block) to help wallet restore but that is SPV specific.
On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
Le 27/03/2014 13:49, Mike Hearn a écrit :
IP32 allows for a range of entropy sizes and it so happens that
they picked 256 bits instead
Hey Addy,
I am seeing a big drop in reachable nodes on
http://getaddr.bitnodes.io/dashboard/ starting from about March 25th 7:20pm
and coming back 9:35pm. Is this a glitch in the monitoring system or did
some real network event happen then?
Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to
Yeah, for those cases we'd need to think of something else. That gets into
the realm of creating our own infrastructure though ...
--
___
Bitcoin-development mailing list
A few months ago I had a conversation with an executive at a Bitcoin
company, and I suggested their developers should get involved with the
development list. I was told that they are all subscribed but refuse to
post. Puzzled, I asked why, maybe the process isn't clear or we didn't talk
about what
Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.
The usual issue is that they lack internet *for some customers*. The place
may well have private wifi or hardwired connections that
In case you didn't see this yet,
http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
If you're using PGP to verify Bitcoin downloads, it's very important that
you check you are using the right key. Someone seems to be creating fake
PGP keys that are used to sign popular
I think it's mostly a UI issue. The recipient needs to understand that what
he received is nothing more than an IOU that can be revoked at any time. If
the UI makes it clear and the user trusts the sender, no problem. BIP70
would work as before.
On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik
On Fri, Mar 21, 2014 at 11:59 AM, Adam Back a...@cypherspace.org wrote:
Maybe its time to explore raw ECDSA signed message based certs.
If you want to create and run a new CA, by all means. But I bet you don't.
So we're stuck with the current system for now.
btw I dont think its quite 4kB.
Sounds very relevant to what we were just discussing on the other thread,
about securing Bluetooth connections and BIP70.
On Fri, Mar 21, 2014 at 11:58 AM, Andreas Schildbach
andr...@schildbach.dewrote:
Access granted. Welcome! (-:
On 03/21/2014 10:11 AM, Chris D'Costa wrote:
Hello
I
Oh, one other reason I found - apparently RIM, at least in the past, has
been telling CA's that they need to pay mad bux for the Certicom ECC
patents. So that's another reason why most certs are still using RSA.
On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn m...@plan99.net wrote:
On Fri, Mar 21
+0100, Mike Hearn wrote:
Oh, one other reason I found - apparently RIM, at least in the past,
has been telling CA's that they need to pay mad bux for the Certicom
ECC patents. So that's another reason why most certs are still using
RSA
SPDY requires SSL and is even more complex than HTTP.
Really, the current protocol we've got (length prefixed protobufs) is just
fine except for the lack of encryption/authentication. For that you need to
do ECDH to establish a shared AES session key, and MAC each packet. Like I
said, it's not
on practical/convenient QR code size?
How much of the payment protocol message size comes from use of x509?
(Just exploring what the options are).
Adam
On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
Encoding entire payment requests into qrcodes is definitely not the way
MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement a reliable secure solution here.
2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net:
Encoding entire payment requests into qrcodes is definitely
The standard has become mBTC and that's what was adopted. It's too late to
try and sway this on a mailing list thread now.
On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk wrote:
The MultiBit HD view is that this is a locale-sensitive presentation
issue. As a result we offer a
BitPay should use mBTC as well. Unless you can point to any major wallets,
exchanges or price watching sites that use uBTC by default?
I think it is highly optimistic to assume we'll need another 1000x shift
any time soon. By now Bitcoin isn't obscure anymore. Lots of people have
heard about it.
Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
than 3123.45 uBTC.
This is subjective though. To me the first price looks like the price of a
cup of coffee (or I just mentally double it). The second looks like the
price of an expensive holiday.
If users really find
Well it looks like the consensus is to do it, instead of talking about
it. I'm going to make sure we get uBTC into the next Armory release.
Hmm - be careful with the word consensus here. A bunch of people on a
mailing list does not make consensus ;)
If you survey other wallets, you'll find
You would only need to change it if there was a sub-satoshi hardfork,
which doesn't seem necessary anytime soon.
+
We shouldn't make any assumptions about the future price of bitcoin to make
the decision.
Hmmm ;) Didn't you just make an assumption about the future price?
This sounds
Can this be calculated in advance knowing the initial transaction size and
the number of signatures required?
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get back from the API doesn't
contain such a 73-byte sentinel value then
You can follow HDW progress in bitcoinj on this branch:
https://github.com/bitcoinj/bitcoinj/commits/keychain
I've been working on it for a couple of months now. Electrum (Thomas V) is
also making good progress, and Trezor already uses HD wallets. I think most
popular end user wallets except
No, this doesn't make any sense. Multisig outputs are a tool you use to
build helpful features, not a feature in and of themselves.
By all means create a nice protocol, implementation and BIP for something
like:
- Creation of multi-user money pools for managing an organisations funds
- Dispute
I'm wondering about whether (don't laugh) moving signing into the kernel
and then using the MTRRs to disable caching entirely for a small scratch
region of memory would also work. You could then disable pre-emption and
prevent anything on the same core from interrupting or timing the signing
I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some
On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach
andr...@schildbach.dewrote:
I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
up the phone the connection breaks.
If the phone isn't willing to immediately authorise then it'd have to fall
back to HTTPS or Bluetooth as
I wonder about the receipt step -- are you generating a PDF on device
and sending it via NFC? This is something that could be supported by the
BIP70 payment protocol. We should try to avoid the second tap, its not
intuitive.
Together, the signed PaymentRequest and the transactions in the
I think maybe the way you do it is to have a NDEF tag that triggers the
app, and then that starts an IsoDep protocol once opened. I *think*.
On Thu, Mar 6, 2014 at 5:55 PM, Andreas Schildbach andr...@schildbach.dewrote:
On 03/06/2014 03:51 PM, Andreas Schildbach wrote:
I'm not sure if
Thanks Alex!
About the video - I'm curious how your device is better than just a regular
tablet. Could you give us the elevator pitch? :)
On Thu, Mar 6, 2014 at 3:39 PM, Alex Kotenko alexy...@gmail.com wrote:
I mean - if with Bitcoin v0.9 transaction fees will become really
floating, and it
if some sort of Stealth address or HD wallet root was the identity gaining
the reputation, then address re-use wouldn't have to be mandatory.
The identity would be the X.520 name in the signing cert that signed the
payment request. It doesn't have to be a difficult to obtain cert. It could
If there was a way for a Bitcoin user to provide feedback on a payment
(ECDSA signature from one of the addresses involved in the payment, signing
an identifier of the payment and a feedback score)
Well now you're getting into the area that I said rapidly got very
complicated.
Define
it's the responsibility of the individual members to maintain their own
good/bad user lists. Would you think that's a good thing or a bad thing to
give the individual players that level of control/responsibility?
If it's explicit, I think it's a non starter and nobody will bother with
it,
Yes please, pull req would be great! I also noticed that escaping doesn't
seem to be necessary, and the resultant de-escaped QRcodes are certainly
much nicer! Thanks!
--
Subversion Kills Productivity. Get off Subversion
On an unrelated note, X.509 is a terrible standard that should be
abandoned as quickly as possible. BitPay is working on a new standard
based on bitcoin-like addresses for authentication. It would be great if
we could work with the community to establish a complete, decentralized
A new practical technique has been published that can recover secp256k1
private keys after observing OpenSSL calculate as little as 200 signatures:
http://eprint.iacr.org/2014/161.pdf
This attack is based on the FLUSH+RELOAD technique published last year. It
works by observing L3 CPU cache
Hey Tom,
Thanks for getting involved! It's great to see someone who would like to
focus on docs.
One project I've been thinking about recently is a Bitcoin Developer
Network subsection of our website. Right now bitcoin.org is entirely
consumer focused. And as you noted, the wiki is undergoing
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote:
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
I'm hoping I can convince Saivann to do a bit of graphics work for this at
some point :-)
Something like a green stamp that appears (like a watermark) in the
background, might be good.
On Sat, Mar 1, 2014 at 8:50 AM, Jeremy Spilman jer...@taplink.co wrote:
On Fri, 28 Feb 2014 23:26:57 -0800,
http://php.net/manual/en/mhash.constants.php
http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples
On 2 Mar 2014 08:44, Mike Hearn m...@plan99.net wrote:
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
On 2 Mar 2014 08:53, Jeremy Spilman
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.
I think for now as long as payment processors
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random c1.devran...@niftybox.netwrote:
I'm wondering about the small business case. A small business or an
individual might not have the technical expertise to perform the
delegation signature.
If they take delivery of an SSL cert from the CA themselves,
On Sun, Mar 2, 2014 at 4:20 PM, Andreas Schildbach andr...@schildbach.dewrote:
I somehow think that it is too early for this heavy kind of extension,
given that the first version of BIP70 isn't even deployed widely let
alone *used*.
Definitely agree - like I said, I publish this only because
Now we're starting to see the first companies deploy BIP70, we're
encountering a need for identity delegation. This need was long foreseen by
the way: it's not in BIP70 because, well, we had to draw the line for v1
somewhere, and this is an issue that mostly affects payment processors. But
I
Thanks for the explanation. I agree that makes sense, and you did actually
explain this before, I just didn't connect the dots :)
The accompanying BIP should explain all this, so the rationale for the
design and how you use it is made clear to developers.
I've CCd Jeff and Stephen on this
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string
There are two possibilities.
One is that the value of transactions with the new lower fee is outweighed
by increased orphan costs and miners refuse to include them en-masse.
Wallet authors lose the staring match and go back to setting higher fees
until such a time as block propagation is
One more thing. The new bitcoin URI in BIP 72 is extremely long and
makes for very dense QR codes.
BIP 73 seems OK except that existing wallets that can scan QR codes will
choke. One reason the new URIs are long is for backwards compatibility.
One thing that makes the URI smaller is not
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
On 20 Feb 2014 16:30, Michael Gronager grona...@mac.com wrote:
As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then
:
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn m...@plan99.net wrote:
We've done forking changes before much faster than a year and that was
with
less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
Bear in mind a separate process doesn't buy you anything without a sandbox,
and those are expensive (in terms of complexity).
On 21 Feb 2014 11:40, Jeff Garzik jgar...@bitpay.com wrote:
[Meta: Bitcoin Core is the newfangled branding of bitcoind /
Bitcoin-Qt reference implementation, in case you
Thanks for the feedback guys!
I would also like to understand the problems you've been having with
certificates in node.js. FYI the CA cert is *not* supposed to be included,
this matches what the code in Bitcoin Core and bitcoinj expects. It may be
that Bitcoin Core accepts a redundant CA cert
but the wallet
receives a callback to verify the payment matches the contract and should
go through.
Please give us some feedback whenever you have the chance. In the meantime
we will start implementing the merchant side and test the code.
Cheers!
On Jan 31, 2014, at 10:13 AM, Mike Hearn m...@plan99
Here’s a new release announcement with full ID’s this time:
The v0.11 tag is signed by Andreas Schildbach’s GPG key (fingerprint E944 AE66
7CF9 60B1 004B C32F CA66 2BE1 8B87 7A60). The commit hash is
410d4547a7dd20745f637313ed54d04d08d28687.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature:
Hello,
I'm pleased to announce the release of bitcoinj 0.11, a library for writing
Bitcoin applications that run on the JVM. BitcoinJ is widely used across the
Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit,
Hive, blockchain.info, the biteasy.com block explorer
That looks OK at a very high level. Things you probably want to think about:
- How to trigger it off the existing payment protocol (no new top level
messages or mime types or uri extensions please)
- Data structures to define the payment schedule
- Do you allow pre-submission of time
Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck chuck+bitcoin...@borboggle.comwrote:
I presume the receipt R=(PaymentRequest,[transactions]) would
Although it should be noted that these binaries don't yet do URI support so
you can't scan a bitcoin URI with r= in it and see the verified merchant
name, etc. I think Andreas plans to do the UI for that in the next update.
On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.comwrote:
In arbitration the merchant could argue the transactions seen on the
network were insufficient.
The arbitrator would presumably have some rules about what is or isn't an
acceptable form of payment.
HTTP has response
straightforward and how I'd expect things to work as a user.
On Thu, Jan 30, 2014 at 12:46 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com
wrote:
Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
Both
If you sent the Payment message and the server goes silent after receiving
it, you retry to delivery. However, the merchant can broadcast the
transactions and force them into your wallet anyway. You could, quite
likely, pay and never get an ACK.
No retries. If there's a timeout the wallet
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumably
Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
inability to come to agreement on when to broadcast vs when to submit via
HTTP, I think.
On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene
And even if you don't care about CoinJoin, not broadcasting the
transaction as soon as the inputs are signed adds implementation complexity
(should you retry if payment_url is unavailable? how many times?
I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If
Todd p...@petertodd.org wrote:
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
Yeah, that's the interpretation I think we should go with for now.
There
was a reason why this isn't specified and I forgot
Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
andr...@schildbach.dewrote:
Because I could not find any standard for Bluetooth URLs, I made
up my own: bt:112233445566 means MAC address 11:22:33:44:55:66.
I would like to
At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
andr...@schildbach.dewrote:
I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?
As I
All insist on handling the link with their download manager, which would
involve an additional click.
That's the expected behaviour, right? That's why I said download and
open. The Bitcoin URI with r= is better because it lets you remove that
second click, but in some contexts the file
I think the right approach for this is to actually implement it and
*then* propose
a BIP. There are so many possible features we could add to the payment
protocol, any other approach would rapidly turn into lots of people
deciding to do the fun bits and often leaving others doing the hard work
, so we can skip the
delimiter for these mediums.
On 01/26/2014 10:24 PM, Mike Hearn wrote:
Which medium is this an issue for? As you note, for files and HTTP
responses it's not a problem in practice. i'd guess nor for NFC tags nor
QR codes.
On Sun, Jan 26, 2014 at 10:11 PM, Andreas
. The embedded messages don't need length prefixes.
On 01/26/2014 11:00 PM, Mike Hearn wrote:
I think for binding the payment protocol to those transports we should
indeed use protobuf varint length prefixes. But it's unnecessary for all
cases. Unless Gavin feels it'd be better
brittleness. The real world experience is that users, or to be exact
wallet authors, turn down SPV privacy parameters until bloom filters
have almost no privacy in exchange for little bandwidth usage.
That's not fundamental though, it just reflects that the only
implementation of this is
We should just perform Unicode canonicalization before any text hits the
crypto code. There are algorithms that automatically resolve such issues.
Although with an English wordlist it would seem to make no difference
anyway.
On Tue, Jan 21, 2014 at 10:01 AM, Gary Rowe g.r...@froot.co.uk wrote:
We have an implementation of the latest spec in bitcoinj, with the wordlist
provided by slush+stick. As far as I can see it's all working fine so LGTM
from us.
On Mon, Jan 20, 2014 at 5:42 PM, slush sl...@centrum.cz wrote:
Hi all,
during recent months we've reconsidered all comments which we
301 - 400 of 642 matches
Mail list logo
