On 01/28/2012 02:45 AM, Luke-Jr wrote:
It's been implemented in many clients for nearly all 2011.
Bitcoin-Qt is just behind the pace. Not relevant.
Bitcoin Wallet for Android implements only parts of this spec:
The hexadecimal notations (x) and exponent notations (X) feel horribly
redundant
Generally I prefer BIP 21 over BIP 20.
I'm neutral on the 'send' parameter - present in both BIPs - which I
don't understand. I think a practical usecase should be given in the BIP.
Also, the 'version' parameter is unclear. What does it mean? Is an oder
defined on versions (1.0b 1.0)? Why is it
On 01/31/2012 07:22 PM, Matt Corallo wrote:
that It is recommended that additional variables prefixed with
mustimplement: not be used in a mission-critical way until a grace
Is the ':' sign actually allowed in URL parameter names
(unescaped/unencoded)? If not, I'd propose an unrestricted char
On 05/03/2012 11:24 AM, Jorge Timón wrote:
On 5/3/12, Andreas Schildbach andr...@schildbach.de wrote:
Can we add Bitcoin Wallet?
Someone said to me that the cell phone apps they had tried were still
too slow. I'm still using an old phone so I didn't know well what to
answer him.
I never
Both blocks
38304 015bb4069249fa1f41ae61d8a7447aaacc33c50dacd3c3654377fa43
and
40320 8011f56b8c92ff27fb502df5723171c5374673670ef0eee3696aee6d
are difficulty transition blocks. However, block 40320 has a difficulty
of 1. I know there is this special testnet rule that allows
Matt, I saw your commit and immediately started using it for testing.
Now I think the bitcoinj side needs some love because not one
transaction is being confirmed (all just pending) when replaying the
blockchain.
On 01/18/2013 05:38 PM, Mike Hearn wrote:
I'm thinking we should actually make the
I had another amendment, which roughly (can't remember the details) has
to do with case-sensitivity of the scheme part and parameter names. If I
remember right, BITCOIN:1d4...?AMOUNT=0.1 would be a correct URI but not
valid in the sense of BIP21 currently.
On 04/24/2013 09:42 AM, Mike Hearn
On 07/22/2013 09:42 PM, Jeff Garzik wrote:
The general goal of the HTTP REST interface is to access
unauthenticated, public blockchain information. There is no plan to
add wallet interfacing/manipulation via this API.
Is it planned to expose the UXTO set of a given address? That would be
On 08/19/2013 10:34 PM, Jeff Garzik wrote:
FWIW, Litecoin 0.8.x entirely removed the internal miner and we warned
people that getwork will be removed in the next major version. Pooler's CPU
minerd which supports both sha256d and scrypt recently grew stratum support.
Perhaps he could be
While it's good to save space, I'm at the moment not convinced that
taking a de-route via an URL is a good idea to begin with.
The main problem is trust. If you scan a QR code from a foreign phone,
you trust that that phone is owned by the one you want to send money to.
By adding the HTTP request
have that problem (unless sophisticated optical
attacks emerge). Also, the HTTP request can fail and/or be slow, making
the whole payment process more difficult than necessary.
On Wed, Sep 25, 2013 at 12:28 PM, Andreas Schildbach
andr...@schildbach.de mailto:andr...@schildbach.de wrote
HTTP also defines success codes (2xx). Are we also talking about ACK
messages now, rather than just REJECT messages?
On 10/28/2013 03:52 AM, kjj wrote:
Any reason not to use actual HTTP codes? I'm not aware of any major
deficiency in them. Most of them won't apply to us, which is fine, they
On 12/01/2013 06:19 PM, Mike Hearn wrote:
Both can be combined into adapting the current generic messages (This
payment should become spendable shortly for incoming and This payment
has not been transmitted yet for outgoing transactions).
What would the new messages say?
Well, for starters
On 12/16/2013 07:28 PM, Mike Hearn wrote:
I don't know how to solve this. Badly designed software that looks
appealing will always be a danger.
One way would be to explicitly warn against some services. For example,
on the Choose you wallet page of bitcoin.org.
Thanks for the explanation.
On 01/13/2014 06:56 PM, Pieter Wuille wrote:
As for you proposal, just be aware I'd like to use the payment protocol
for face to face payments as well. That meant payment request via NFC or
QR, payment message and payment confirmations via Bluetooth. I think it
On 01/13/2014 06:56 PM, Pieter Wuille wrote:
I want to avoid the case where a transaction confirms, but the
associated payment is not delivered. If there is a reasonable chance
that this case occurs in normal operation, it means the payment
transmission cannot be relied upon.
I was thinking
On 01/14/2014 11:45 AM, Mike Hearn wrote:
Imagine you get a good offer (payment request) from a merchant. You
would like to accept that offer, however the merchant has changed his
mind.
Usually if the merchant has not delivered, then at that point it's not a
problem and he is
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 Schildbach
andr...@schildbach.de mailto:andr...@schildbach.de wrote:
I'm experimenting with BIP70/71 (payment
As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates. Their devices may be only
badly connected to the internet or in some cases not at all. I've
implemented a prototype on
On 01/27/2014 03:54 PM, Gavin Andresen wrote:
The purpose of PaymentACK is to give the customer reassurance that their
payment request has been received and will be processed (or not).
If it is syntactically incorrect or invalid in a way that the payment
processor can detect right away then
On 01/27/2014 07:18 PM, Andreas Schildbach wrote:
Rather than pack a file into a URL, if you don't want to
use the current r= extension it's better for apps to just register to
handle .bitcoinpaymentrequest files / the right MIME type. Downloading
it and opening it would do the right thing
://github.com/schildbach/bitcoin-wallet/releases/tag/v3.30-bitcoinj0.11
On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments. The general assumption is that
individuals don't own X.509 certificates
/schildbach/bitcoin-wallet/releases/tag/v3.32
(also published to the corresponding channels on Google Play)
On 01/30/2014 11:46 AM, Andreas Schildbach wrote:
Just a small update. I merged the code to my bitcoinj-0.11 branch and
put up binary .apk files for experimentation. Just make sure to tick
I'm starting a thread on proposed changes on BIP70 based on my
experience in implementing the payment protocol in Bitcoin Wallet:
- certificate chain in pki_data: I think it should be required that is
most contain the first certificate PLUS all intermediate certificates
(if any), but NOT the root
On 02/18/2014 08:14 PM, Ryan X. Charles wrote:
The most important missing piece of the payment protocol is that is has
no concept of the status of a payment after it has been made. What if
the payment is too little? Too much? What if it is never confirmed? What
if it is confirmed, but very
/Payment-Requests
If you have any questions about compatibility, don't hesitate to contact me.
On 01/27/2014 12:59 PM, Andreas Schildbach wrote:
As promised I'd like to present my work done on leveraging the payment
protocol for face-to-face payments
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. It's ok if some people decide to let
the app do risk analysis, but you cannot force it onto users by picking
a protocol that cannot deal with manual verification. Users should
always have
On 03/06/2014 02:44 PM, Mike Hearn wrote:
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 normal.
Ok, that would be
Not sure if you've seen it, but here is how we do NFC right
now http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
Thanks for the video! It's always good to see these things in action so
you can start believing in it.
For now this is just an NDEF URI message with Bitcoin URI inside,
On 03/06/2014 03:51 PM, Andreas Schildbach wrote:
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 normal.
Ok
On 03/06/2014 07:03 PM, Alex Kotenko wrote:
Supporting Bluetooth is optional in the sense that if a wallet should
not support it, you will still receive the transaction via the P2P
network. So I'd say definately go for Bluetooth.
Yes, it's part of the plan. Just again - I need
On 03/10/2014 04:09 PM, Alex Kotenko wrote:
Yes, I'm certain about that we need to switch to BIP70 asap. As I said
earlier - support among the wallets is the biggest problem here really.
Only Andreas' Wallet supports it right now AFAIK, and even in there it's
only as LABS feature, so will
Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
I must admit I was not aware if this thread. I just watched other
wallets and at some point decided its time to switch to mBTC.
On 03/13/2014 02:31 PM, Mike Hearn wrote:
The standard has become mBTC and that's what was
/2014 02:40 PM, Andreas Schildbach wrote:
Indeed. And users were crying for mBTC. Nobody was asking for µBTC.
I must admit I was not aware if this thread. I just watched other
wallets and at some point decided its time to switch to mBTC.
On 03/13/2014 02:31 PM, Mike Hearn wrote:
The standard
as a
price in some currency.
A number with more than two decimals is just not percieved as a price
but as a geeky something that you rather convert to local currency.
Tamas Blummer
Bits of Proof
On 14.03.2014, at 15:49, Andreas Schildbach andr...@schildbach.de
mailto:andr...@schildbach.de
solve this problem for good.
Instead mBTC is a confusing step in-between.
Tamas Blummer
http://bitsofproof.com
On 14.03.2014, at 16:02, Andreas Schildbach andr...@schildbach.de
mailto:andr...@schildbach.de wrote:
By that definition 3.56 is a price. Maybe I misunderstood you and you're
On 03/20/2014 03:22 AM, Alex Kotenko wrote:
Right now, before BIP70, I'm sending BIP21 URI via NFC or QR code, and I
need to still be able to use it for backwards compatibility. But at the
same time I want to be able to support BIP70. And also I want to avoid
using external servers, the
On 03/20/2014 05:14 PM, Alex Kotenko wrote:
Hmm, if we're inventing an URI for bluetooth, I'd rather follow existing
URI's patterns. BT is strictly point-to-point connection, so BT MAC
should be considered as server address, and payment request ID can be
considered as request path. Probably
On 03/20/2014 01:12 PM, Adam Back wrote:
Whats a sensible limit on practical/convenient QR code size?
Technically 3 KB. In my experience codes above 1.5 KB become impossible
to scan (ZXing scanner, 3 years ago). You will want to stay below 500
bytes for convenient scanning. That said, I'm
On 03/20/2014 06:31 PM, Jeff Garzik wrote:
Afaik, BIP73 needs an external server (the web server).
Yes. Internet connectivity is not a rarity these days. Near-field
web servers also work fine.
Unfortunately it still is. At least here in Germany.
+1
I couldn't do a better job at describing my motivation behind trying to
stuff payment requests into QR codes.
On 03/20/2014 10:52 PM, Roy Badami wrote:
On Thu, Mar 20, 2014 at 07:31:27PM +0100, Mike Hearn wrote:
Yes, this overlaps somewhat with the PKI signing in BIP70, but not
entirely
Access granted. Welcome! (-:
On 03/21/2014 10:11 AM, Chris D'Costa wrote:
Hello
I wonder if I could be granted access to post to the dev list. My project is
the Meek hardware wallet, and we are working on a solution to avoid MITM
attacks when communicating a pay-to information over a
But these cases are the norm, rather than the exception. Of all these
places I spend my money at during the day I hardly ever know their
official name. I'm thinking in terms of bakery, indian restaurant or
snack vending machine.
In Germany usually businesses are named like the people that run it.
Thanks for starting the discussion on finding a better structure.
For me, the most important thing is either we're 100% interoperable or
0%. There should not be anything inbetween, as users will delete seeds
without knowing there is still money in them on another implementation.
I heard from
I see the problem.
However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment).
You're probably aiming for an expires field? How would you refund a
payment after expiry? Note its not
:
On Fri, Mar 28, 2014 at 12:25 PM, Andreas Schildbach
andr...@schildbach.de mailto:andr...@schildbach.de wrote:
However, I don't see how PaymentDetails can be an answer. None of the
fields (other than outputs and network) can be known in advance (at the
time of the initial payment
On 03/28/2014 07:19 PM, Mike Hearn 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
...@gnomon.org.uk wrote:
On Fri, Mar 28, 2014 at 09:56:57PM +0100, Andreas Schildbach wrote:
On 03/28/2014 07:19 PM, Mike Hearn 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
They're _not_ phasing out into SPV wallets from what I can say. At
around the 24th of February, there has been a sharp change of the
current installs graph of Bitcoin Wallet. That number used to grow at
about 20.000 per month. After that date until now, it just barely moves
horizontal.
My guess
On 04/08/2014 05:46 PM, slush wrote:
I understand each client will implement things a little bit different,
for example the current plan is bitcoinj will hold all keys in memory
and start reusing keys on low resources. Electrum uses a chain for their
private purpose. Etc.
Does anyone use or plan to use the wallet structure part of the BIP32
document?
I suggest removing it from the document and maybe instead point at
BIP43. That new specification proposal just defines a purpose and
leaves everything else to the inventor of that purpose. The idea it that
over time a
I'm bringing this issue up again. The current Bitcoin DNS seed
infrastructure is unstable. I assume this is because of we're using a
custom DNS implementation which is not 100% compatible. There have been
bugs in the past, like a case sensitive match for the domain name.
Current state (seeds
On 05/15/2014 07:48 PM, Gregory Maxwell wrote:
On Thu, May 15, 2014 at 4:50 AM, Andreas Schildbach
andr...@schildbach.de wrote:
I'm bringing this issue up again. The current Bitcoin DNS seed
infrastructure is unstable. I assume this is because of we're using a
custom DNS implementation which
Apparently British Telecom also cannot speak to Peter Todd's server.
That another very large ISP in Europe.
On 05/15/2014 01:50 PM, Andreas Schildbach wrote:
I'm bringing this issue up again. The current Bitcoin DNS seed
infrastructure is unstable. I assume this is because of we're using
: desktopv2.bluematt.me
Address: 152.23.202.18
And that address doesn't connect on port 18333.
On 05/16/2014 08:53 PM, Matt Corallo wrote:
This is very strange...when did you run this test and can anyone else
reproduce this?
Matt
On 05/15/14 11:50, Andreas Schildbach wrote:
testnet
I think the best way to contribute to the infrastructure is actually
what we're doing: Test the current infrastructure and point out where it
is not working. Trying to find solutions for problems.
There is nothing gained by throwing additional hardware at a problem if
the problem itself isn't
On 05/17/2014 02:02 PM, Alex Kotenko wrote:
So, my understanding is that atm we have no working DNS seeds at the
testnet3, right? There are two DNS seeds known, of which one is
unreachable atm, and another one is giving just one IP address, which is
also a dead node.
Yes, that's my
One problem we couldn't figure out here though - how to protect the
notes from unauthorized redeem. Like if someone else tries to reach your
wallet with his own NFC - how can we distinguish between deliberate
redeem by owner and fraudulent redeem by anybody else with custom built
long range
Jerry, some feedback on generating space-efficient QR codes. QR codes
have 4 possible encodings, see Storage:
http://en.wikipedia.org/wiki/QR_code
The encoding you're proposing in BIP81 switches you to binary mode
without actually using all the bits. So you'll end up with bloaty QR
codes. One fix
Great, thanks for this contribution!
Do you plan to have your seeds reachable on port 53 eventually?
Currently bitcoinj cannot deal with nonstandard ports I think.
On 05/21/2014 11:23 AM, Alex Kotenko wrote:
okay, I've set it up with bind forwarding requests to two dnsseeds
running on
Kotenko
2014-05-21 12:03 GMT+01:00 Andreas Schildbach andr...@schildbach.de
mailto:andr...@schildbach.de:
Great, thanks for this contribution!
Do you plan to have your seeds reachable on port 53 eventually?
Currently bitcoinj cannot deal with nonstandard ports I think
Thanks for looking at the issue.
Unfortunately, it still fails for me:
$ nslookup testnet-seed.bitcoin.petertodd.org
Server: 127.0.1.1
Address:127.0.1.1#53
** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL
Like I said, can you look at the logfiles how the
at 09:12:10PM +0200, Andreas Schildbach wrote:
Thanks for looking at the issue.
Unfortunately, it still fails for me:
$ nslookup testnet-seed.bitcoin.petertodd.org
Server: 127.0.1.1
Address: 127.0.1.1#53
** server can't find testnet-seed.bitcoin.petertodd.org: SERVFAIL
On 05/27/2014 12:39 AM, Peter Todd wrote:
On 27 May 2014 01:12:05 GMT+03:00, Andreas Schildbach
andr...@schildbach.de wrote:
You're very quick to point at others. Especially since they run
software that had the time to mature for about 30 years, and the
protocol didn't really change since
Just a quick comment:
The supports_instant field seems redundant to me. First, as per your
spec, you can derive it from trusted_instant_providers. And second, why
do you need it at all? Protobuf is designed so it will simply ignore
fields you don't know. So you can just send the instant_* fields
be signed. Can you
briefly describe the whole flow of messages on an example, including the
BIP70 messages?
Should we allow adding multiple signatures (from different instant
providers or maybe while transitioning to another PKI)?
On 06/15/2014 11:22 AM, Lawrence Nahum wrote:
Andreas Schildbach
I think it should be made more clear what's the reference price for the
discount. In Germany, we generally don't use credit cards but rather
EC-Cards, which is already much cheaper. Or maybe for some merchants
the only alternative is cash, and they would still offer a Bitcoin discount.
Also,
On 07/01/2014 10:18 AM, Mike Hearn wrote:
However it's not ideal at the moment. Basically the main problem is
that in the BIP72 there is no way to provide a fallback alternative
URI for payment request fetch if client wallet supports BIP70 but
doesn't not support fetching over
Does r[]= really need to be encoded as r%5B1%5D= ? In this case, I'd
advocate for a simple array parameter name, like rs= (plural of r).
Length really does matter for QR codes.
I'm fine with either multiple r= params or exactly one r= plus zero to
many r[]= params. Although I think it is a
checking for any duplicate parameters and treating the entire URI as invalid
if duplicate parameters exist (following the parameter pollution suggestions).
-
Michael Wozniak
On Jul 1, 2014, at 10:59 AM, Andreas Schildbach andr...@schildbach.de wrote:
Does r[]= really need to be encoded as r
I think generally control-characters (such as \u) should be
disallowed in passphrases. (Even the use of whitespaces is very
questionable.)
I'm ok with allowing pile-of-poo's. On mobile phones there is keyboards
just containing emoticons -- why not allow those? Assuming NFC works of
course.
Can you provide the rationale for standard practice? For example, why
should whitespace be allowed? I regularly use trim() on any passphrase
(or other input ftm).
So what's the action point? Should we amend the spec to filter control
characters? That would get rid of the \u problem.
On
Guys, you are always talking about the Unicode astral plane, but in fact
its a plain old (ASCII) control character where this problem starts and
likely ends: \u.
Let's ban/filter ISO control characters and be done with it. Most
control characters will never be enterable by any keyboard into a
, 2014 at 11:17 AM, Andreas Schildbach
andr...@schildbach.de mailto:andr...@schildbach.de wrote:
Guys, you are always talking about the Unicode astral plane, but in fact
its a plain old (ASCII) control character where this problem starts and
likely ends: \u.
Let's ban/filter
whatever
implementation) and I will verify it decodes properly in bitcoinj?
On 07/16/2014 12:46 PM, Andreas Schildbach wrote:
I will change the bitcoinj implementation and propose a new test vector.
On 07/16/2014 11:29 AM, Mike Hearn wrote:
Yes sorry, you're right, the issue starts
, Andreas Schildbach
andr...@schildbach.de wrote:
Damn, I just realized that I implement only the decoding side of BIP38.
So I cannot propose a complete test vector. Here is what I have:
Passphrase: ϓ␀Ѐ (\u03D2\u0301\u\U00010400\U0001F4A9; GREEK
UPSILON WITH HOOK, COMBINING ACUTE ACCENT
me if there are other weird issues lurking. Would definitely
sleep better with a more restricted character set.
On 17 Jul 2014 00:04, Andreas Schildbach andr...@schildbach.de
mailto:andr...@schildbach.de wrote:
Please excuse me. I had a more thorough look at the original problem
Are you aware of bitcoinj?
http://bitcoinj.github.io/
It contains everything to plug together a basic SPV wallet and runs in
the JVM.
On 07/30/2014 09:38 AM, Caleb Roger Davis wrote:
Yes, I was thinking something on the JVM, I have a big interest in
Clojure right now (am a long time Java
On 08/05/2014 05:11 PM, Mike Hearn wrote:
Oh, I forgot to mention something important. Ridiculously, the default
package repository Maven uses was not protected by SSL up until a few
days ago. They made it available via SSL now, but you have to tell
Maven about the new URL. I guess they'll
On 09/12/2014 12:11 PM, Mark van Cuijk wrote:
On 12 Sep 2014, at 11:55 , bitcoin-development-requ...@lists.sourceforge.net
wrote:
The hash is meant to link the trust anchor (e.g. the QR code) to the
payment request message in a secure way. This will solve the problem
several apps are
On 09/12/2014 03:49 PM, Mike Hearn wrote:
(1) Base64 of SHA256 seems overkill. 256 bits of hash is a lot. The risk
here is that a MITM intercepts the payment request, which will be
typically requested just seconds after the QR code is vended. 80 bits of
entropy would still be a lot and take a
I agree that this would be another way of achieving the same goal. I'd
be fine with that if there is a majority.
However, I also see downsides of this approach:
1. It's more complicated. It touches more BIPs, and although signing is
terribly difficult its still more difficult than just hashing.
On 09/12/2014 08:43 PM, Aaron Voisine wrote:
Should BIP72 require that signed payment requests be from the same
domain,
Although it currently does not seem to be used that way, I'd like to see
merchants sign their payment requests but store them on their payment
processors server. Currently if
On 02/02/2015 03:47 PM, vv01f wrote:
Uff, I would expect MMDD there so it's human readable as well.
Those strings are not meant to be read by humans. MMDD is more
complicated than necessary, given that Bitcoin deals with seconds since
epoch everywhere.
First that is a pitty .. as
On 02/02/2015 03:56 PM, Pavol Rusnak wrote:
To me it seems more important to describe how addresses should be
discovered (i.e. to scan xpub/0/i and xpub/1/j chains using gap limit G)
instead of how the xpub was created/obtained (bip32 vs bip44).
What do you thing about changing ?h=bip32 to
On 02/02/2015 12:33 PM, Mike Hearn wrote:
I looked at what Andreas is doing a few days ago - basically it's just
an xpub string with a ?a=bc=d query string added to the end, with a
hierarchy type specifier and something else I forgot, encoded into a QR
code.
It's h=bip32 for the hierarchy
On 02/02/2015 01:59 PM, Pavol Rusnak wrote:
It's h=bip32 for the hierarchy used and
Do I understand this correctly and h=bip32 hierarchy means that both
xpub/0/i and xpub/1/j chains are scanned? (So it applies to BIP44
generated xpubs as well?)
Yes, except that BIP32-hierarchy and BIP44
Thanks Paul, for writing up your protocol!
First thoughts:
For a BIP standard, I think we should skip bitcoin: URIs entirely and
publish BIP70 payment requests instead. URIs mainly stick around because
of QR codes limited capacity. BIP70 would partly address the copycat
problem by signing
On 02/06/2015 01:36 AM, Eric Voskuil wrote:
The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT. For payment
purposes the lower bandwidth isn't much
On 02/03/2015 10:33 AM, Levin Keller wrote:
Why not have more descriptive parameters? Saving on data?
Yes. QR codes are very size sensitive.
--
Dive into the World of Parallel Programming. The Go Parallel Website,
On 02/03/2015 01:22 AM, Pavol Rusnak wrote:
Hm, let me put the questions the other way around:
What gap limit should a wallet use if it encounters h=bip32?
It should follow the spec. I know BIP32-hierarchy is short on gap
limits, which is why (amongst other reasons) I expect
On 02/03/2015 11:10 AM, Pavol Rusnak wrote:
Another option that might make sense is the block number.
Not really IMHO. Keys can be used on multiple blockchains.
--
Dive into the World of Parallel Programming. The Go
Thanks Thomas, for sharing your experience!
I'd like know why you think it's a problem that BIP43 is tied to BIP32?
I understand we all agreed at least on the BIP32-derivation spec
(excluding the BIP32-hierarchy spec)?
For reasonably skilled users your points are valid, but I'm sure you
also – like me – encountered the kind of user who has absolutely no clue
but thinks he understands. S/he will ignore warnings and run into
troubles. This generates a huge amount of support cases and likely tears
about lost coins.
Thy, your message threading is broken. Can you make sure your mail
program uses the correct message ID when replying?
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and
That doesn't work for mobile wallets, because we need to consider the
offline case. To fix this, we'd need to extend BIP70 to tell the
merchant where to forward the half-signed transaction to. Then again I'm
not sure if we want that, for privacy reasons. In any case, practical
multisig is still a
On 03/12/2015 01:11 AM, Gregory Maxwell wrote:
Ultimately, the most fundamental compatibility is guaranteed: you can
always send your funds to another wallet. This always works and
guarantees that you are never locked in to a single wallet. It is well
tested and cannot drive any software in
On 03/12/2015 07:27 PM, Natanael wrote:
Den 12 mar 2015 17:48 skrev Mike Hearn m...@plan99.net
mailto:m...@plan99.net:
b) Creation date is just a short-term hack.
I agree, but we need things to be easy in the short term as well as
the long term :)
The long term solution is clearly to
Congrats on the release! Electrum is a very nice wallet.
On 03/01/2015 04:23 PM, Thomas Voegtlin wrote:
Dear Bitcoin devs,
I just tagged version 2.0 of Electrum:
https://github.com/spesmilo/electrum/tree/2.0
The electrum.org website will be updated later today. The release
notes are a
On 02/23/2015 01:18 PM, Mike Hearn wrote:
I read from your answer that even if we use ECDHE, we can't use it for
every situation.
Which situations do you mean? I think it can be used in every situation.
It's the opposite way around - a fixed session key in the URI cannot be
used in
1 - 100 of 113 matches
Mail list logo
