On 05/25/2015 11:05 PM, Peter Todd wrote:
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote:
I see this behavior all the time. I am using the latest release, as far as
I know. Version 4.30.
The same behavior occurs in the Testnet3 variant of the app. Go
On 05/25/2015 10:03 PM, Matt Whitlock wrote:
On Monday, 25 May 2015, at 8:41 pm, Mike Hearn wrote:
some wallets (e.g., Andreas Schildbach's wallet) don't even allow it - you
can only spend confirmed UTXOs. I can't tell you how aggravating it is to
have to tell a friend, Oh, oops, I can't pay
Actually your assumption is wrong. Bitcoin Wallet (and I think most, if
not all, other bitcoinj based wallets) picks UTXO by age, in order to
maximize priority. So it keeps the number of UTXOs low, though not as
low as if it would always pick *all* UTXOs.
On 05/09/2015 07:09 PM, Jim Phillips
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 04:09 PM, Jan Vornberger wrote:
I'm still concerned that the fact, that Bluetooth is often disabled, is a
problem for the UX. And it's not just a one-time thing as with NFC,
which is - in my experience - also often disabled, but then people turn
it on and leave it on.
It's the
Yeah, you'd be limited to simple usecases. X509 signing or lots of
outputs will make the QR code hard to scan. However, if all you want to
do is send to a custom script (without using P2SH) I invite you to have
a look at
On 02/26/2015 12:14 PM, Oleg Andreev wrote:
Base43 is the same as any BaseX standard, but using a different alphabet
(43 characters). It's meant to be used for efficiently storing binary
data into QR codes. The alphabet is picked to match the 'Alphanumeric'
input mode of QR codes as closely
On 02/24/2015 11:41 AM, Mike Hearn wrote:
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
bitcoin:3aBcD?bt=
Yes it would. I guess then, the server would indicate both the script,
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
On 02/23/2015 11:58 AM, Mike Hearn wrote:
You're right that just sending the session key is simpler. I
originally suggested doing ECDHE to set up an encrypted channel
for the following reasons: [...]
I read from your answer that even if we use ECDHE, we can't use it for
every situation. So in
mess with an attack like that, in which case
everything we could do locally (other than the payment request signing
using PKI), is useless.
I'm not a cryptography expert so I apologize if there is something
rudimentary that I am missing here.
Andy Schroder
On 02/22/2015 08:02 PM, Andreas
On 02/22/2015 11:37 PM, Andy Schroder wrote:
Andreas and I had a number of private discussions regarding the
payment_url parameter. I had suggested a additional_payment_urls
repeated parameter, but he didn't seem to like that idea and I
personally am indifferent, so that is why we decided to
On 02/23/2015 12:32 AM, Andy Schroder wrote:
I guess we need to decide whether we want to consider NFC communication
private or not. I don't know that I think it can be. An eavesdropper can
place a tiny snooping device near and read the communication. If it is
just passive, then the
Jan, this is great stuff! Thanks for sharing your experiences.
I think the 4k payments requests issue must be solvable somehow. I had
no trouble transmitting that amount via NFC, although yes a bit of delay
was noticable.
About payment_url: Protobuf allows changing optional to repeated and yes
On 02/22/2015 11:39 PM, Eric Voskuil wrote:
The MAC address (and resource name) should be encoded using base58. This
is shorter than base16, is often shorter than base64, better
standardized and does not require URI encoding, and is generally
available to implementers.
Of course this is just
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
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/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
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
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 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
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
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
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
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
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
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 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,
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
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
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
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
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
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
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
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'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
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
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.
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
...@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
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
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
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
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
/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
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
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
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
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
/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 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
/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
://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
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
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
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
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 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.
1 - 100 of 113 matches
Mail list logo
