For a BIP standard, I think we should skip bitcoin: URIs entirely and
publish BIP70 payment requests instead.
Agreed - it's not clear to me at all that this partial address scheme is
actually secure. The assumption appears to be that the MITM must match the
address prefix generated by the
This sounds horrible. You could basically monitor anyone with a wallet in
a highly populated area and track them super easily by doing facial
recognition.
We're talking about BLE, still? The radio tech that runs in the so called
junk bands because propagation is so poor?
My watch loses its
I'm imagining myself walking around broadcasting my photo and MAC
address while hucksters push payment requests to me for approval
I hate to break it to you, but you broadcast a photo of your face every
time you walk outside ;)
Bluetooth MAC addresses are random, they aren't useful
Even if a user could get the BIP70 URL in the URI, they would still need
internet to access the URL.
The way Bitcoin Wallet does it, the bitcoin URI includes a MAC address
where you can download the request from. BIP70 does not depend on internet
access or HTTP, plus, you don't have to sign
TREZOR like devices with BIP70 support and third party cosigning services
are a solution I really like the sound of. I suppose though that adding
BIP70 request signature validation and adding certificate revocation
support starts to balloon the scope of what is supposed to be a very simple
Do you have anything that is NOT some web application?
Bitcoin Authenticator is a desktop app+mobile app pair. It pairs with your
phone over wifi, cloud push, maybe Bluetooth as well. I forget exactly.
It's done in the same way as Lighthouse, so it runs Win/Mac/Linux on
desktop and Android on
In sending the first-signed transaction to another for second signature,
how does the first signer authenticate to the second without compromising
the independence of the two factors?
Not sure what you mean. The idea is the second factor displays the
transaction and the user confirms it
I see how BIP 70 verifies the payment request, however, is there any way
to verify that the transaction signed by the wallet matches the request
before it is sent to the blockchain (and how can this support out of band
verification)?
No. It cannot be done in the Bitcoin context. Your wallet
TREZOR does not support BIP70. I think they planned to work on it after
multi-sig support, which is now done, so I'm hoping that it's next on their
roadmap.
The signing features of BIP70 have (fortunately!) been implemented by
payment processors quite early, before we really have the client side
Hi Martin,
You're on the right lines. Your writeup is pretty similar to the high level
overview given here though:
https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
To make 2-of-3 dispute mediation works requires implementing a wallet that
supports it, and the tools
I could look at implementing it someday, but now I'd like to receive
feedback from community.
IMO it's better to pair a protocol spec with an implementation. For one, it
can show up issues in the design you didn't think of. For another,
implementation is a lot more work than speccing out a
Alipay handled up to 2.85 million transactions per minute, and 54 percent
of its transactions are made via mobile device.
I know China is a very big place but even so - 47,500 transactions per
second would be almost quintiple what Visa handles across the entire world.
With only 300 million
It is not fear, it is field experience.
JSON has proven to be a bug generator for the reasons already stated.
To back Jeff up on this point, today we see this story:
http://www.theregister.co.uk/2015/01/27/trivial_hole_left_black_phones_open_to_plunder/
The maker of BlackPhone – a mobile
I'm frankly _horrified_ to learn that BitcoinJ ships its own root CA
certificates bundle. This means that, if a root CA gets breached and a
certificate gets revoked, all BitcoinJ-using software will be vulnerable
until BitcoinJ ships an update *and* the software in question pulls in the
new
and not depends on the transport.
But a standard that just use JSON and HTTPS, even if less flexible that
BIP70, would make it easier and sufficient for today's use case.
On Wed, Jan 28, 2015 at 5:55 PM, Mike Hearn m...@plan99.net wrote:
My point is not that there is a limitation in BIP70. My point
On the other hand, if you charge the developer (and not the plateform) to
check certificate validity, it means that you have to develop a different
codebase for all plateform you are targeting, because each plateform store
trusted root certificate in a different manner with different APIs,
My point is not that there is a limitation in BIP70. My point is that you
put the burden of certificate verification on developer's shoulder when we
can just leverage built in HTTPS support of the platform.
Platforms that support HTTPS but not certificate handling are rare - I know
HTML5 is
I hear that. But I don't see why mainstream wallets and wallets
designed for crypto research should not share a common core.
I think there was some misunderstanding. I was saying they *could and
should* share common cores, so we are in agreement without realising it :)
I also didn't mean to
The engineers at Google were well aware that ASN.1 existed. I can assure
you of that, because I was one of them.
The protobuf FAQ has a very polite take on the matter:
https://developers.google.com/protocol-buffers/docs/faq
This email thread gives more enlightenment:
I'm a bit confused. It's been a long time since I looked at protobuf (and
will have to dig into it soon), but I seem to recall it doesn't have any of
the determinism properties you guys just said.
It's not guaranteed no, which is why we store signed sub-messages as byte
arrays instead of
Firstly, apologies to Nathan for not actually providing feedback on his
protocol. I've put pondering it onto my mental todo list. The notion of a
payment tree is interesting but complicated - I would need to think about
it and maybe draw myself some diagrams before having useful feedback here.
If
The original design is documented at the bottom of here:
https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party
In this design, time locked transactions can be broadcast across the
network and replaced by broadcasting a new transaction that
This needn't be so, once an optional identity layer, modeled after the
Internet itself, is provided, as proposed in late August of last year on
this mailing list
I think the observation about Target vs Bitcoin exchanges is a sharp one,
but I'm not sure how your proposal helps. You say it's
A limitation on most existing micropayment channel ideas is that payments
can only flow in one direction.
It's worth noting that the original protocol as designed by Satoshi did not
have this limitation. It has evolved this way because of ad-hoc DoS fixes
over time (btw I'm not saying they
Can you explain further where limitations and problems were hit?
Well, look at the feature list :)
The biggest need from my POV is querying support. It's awkward to try and
retrofit flexible key=value pair queries onto DNS, it just wasn't designed
for that. With HTTP it's easy. This will
Could you explain a bit further Sergio? I'm not sure I fully understand the
proposal.
How does adding inputs to a coinbase differ from just having pay-to-fee
transactions in the block?
--
Dive into the World of Parallel
Hi there!
Lately we have been bumping up against the limitations of DNS as a protocol
for learning about the p2p network. As a proposal for how to address this,
I have written a new network crawler and seed:
https://github.com/mikehearn/httpseed
It implements a standard DNS seed with a minimal
Hi there,
I hope everyone who celebrates Christmas is having a relaxing and enjoyable
break! :)
I'd like to announce Bitcoin XT https://github.com/bitcoinxt/bitcoinxt, a
patch set on top of Bitcoin Core 0.10rc1 that focuses on enhancements to
the peer to peer protocol. It is reproducibly built
Finally, distributors of consumer wallets can use this research in
order to distribute their wallet with policies which may be less prone
to Tor-specific attacks. Or leave this out altogether if their
audience has different expectations for connecting to Bitcoin.
Sure. I guess there will be
I wrote a little Javascript program
https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/javascript/payprotocol.js
to print some minimal protobufs to base64.
Result for a multisig output:
[As an aside I agree that there are lots of things to improve here,
but the fact that users can in theory be forced off of tor via DOS
attacks is not immediately concerning to me because its a conscious
choice users would make to abandon their privacy
Bitcoin already has a large population
DKIM is hardly a PoW; signing is cheap and gets cheaper all the time. I
used to work in the email business and big bulk mailers all spent far more
CPU time on other aspects of their business, the overhead of DKIM is
irrelevant.
PoW didn't work in the anti spam world because it (amongst other
Here is a summary of current developments in the space of decentralised
2-factor Bitcoin wallets. I figured some people here might find it
interesting.
There has been very nice progress in the last month or two. Decentralised
2FA wallets run on a desktop/laptop and have a (currently always
of single device compromise.
It also makes funds unspendable if -either- device's keys become lost.
On Sat, Nov 8, 2014 at 5:04 PM, Mike Hearn m...@plan99.net wrote:
Here is a summary of current developments in the space of decentralised
2-factor Bitcoin wallets. I figured some people here
I am familiar with the Princeton threshold signature but I was under the
impression a single key needed to be generated on a single device then
split and distributed.
Does this scheme work the same way?
No, it doesn't. Neither device ever sees as master private key.
Who benefits from not fixing bugs in Bitcoin?
We can bring up politics if you want.
No, please don't. That question was rhetorical, not an invitation for you
to try and convince bystanders that anyone who disagrees with you is a
shadowy Agent Of Centralisation or an idiot. You use that
This is another problem that only exists because of the desire to soft
fork. If script 2.0 is a hard fork upgrade, you no longer need weird
hacks like scripts-which-are-not-scripts.
--
Could you explain a little further why you think the current approach is
statistically incorrect? There's no doubt that the existing estimates the
system produces are garbage, but that's because it assumes players in the
fee market are rational and they are not.
Fwiw bitcoinj 0.12.1 applies the
This feature makes possible Bitcoin Core to read a balance of any
public address via RPC call or, after importing the balance, it became
available only via QT interface?
Neither. A watching wallet still has to be synced with the chain in the
same way as any other wallet, i.e. after adding an
Hey Andy,
Thanks for starting this discussion!
One thing this brings up is the never-resolved issue of whether BIPs should
document how we'd *like* things to work, or how things *actually do* work.
BIP32 is an example of the former - it was new technology and the spec was
finalised before any
Great idea. Jeff Garzik was looking for a better mailing list solution
than SourceForge, but assuming
there isn't a clearly better solution I think we should create a
strictly moderated bitcoin-bips@lists.sourceforge list.
Let's stay away from SF.net or any mailman-controlled lists if at
I don't care much what exact list software/service is used, but lists.sf.net
hasn't changed in years and is basically dying. Trashing all @yahoo
accounts because ancient mailman does a MITM attack on people's email is no
good, it's not any better than a web proxy that breaks every SSL
connection.
I'm sure this suggestion will go down like a lead balloon, but Bitcoin Core
is not the first project that's had issues with Linux distros silently
modifying their software as they package it. In this case Luke has changed
things to be closer to what users expect, which is good to see, but I
expect
Opinion: if a soft work works, it should be preferred, if for no other
reason than once a hard-fork is planned, the discussion begins about
what else to throw in. To minimize the frequency of hard-forks, the
time for that is when the change being considered actually requires one.
I'm not
Yes, you're right. I didn't consider that case. But the problem is that
this is not automatic. Currently there is a clear division between
miners how will not take the kickback (irrrational) and miners who will
(rational).
This seems to come up a lot. Your definition of rational is a short
That is easy to change; I'll submit a pull request.
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major
release. If there's going to be an intermediate release (6 months?) which
lays the groundwork for
the block size being lower than the instant offered demand (there is
always a backlog) are both things which address the concern of this thread.
:)
I'm skeptical such a situation can ever be stable. People have no incentive
to create a transaction that will remain stuck in the backlog
Hey Kristov,
I hate to reply to a release that includes a huge number of new features
with yet another feature request, so -- with apologies -- any plans for
bitcoinj to support stealth address sending and/or receiving?
Stealth addresses and SPV don't mix well, so no. I wrote up a description
I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most
popular Bitcoin libraries. It is used by at least four Android wallets, three
desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse,
BlueMatt’s relay network, bitpos, countless alt coin wallets, for
Alright. It seems there's no real disagreement about how the opcode
behaves. Perhaps a time limit would be appropriate to stop people creating
outputs locked for 100 years is bitcoin even likely to exist in 100
years? The entire history of computing is not even that old, seems hard to
imagine
A few thoughts on this:
(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 long time to brute
Your example doesn't have an address in it at all, so isn't compatible with
non-BIP70 wallets. Maybe for QRcodes specifically there are no longer any
such wallets out there. For clickable links it can still be an issue.
I thought SHA1 has a bad reputation these days, and we don't save much
by
a few characters to a normal backwards-compatible QR code,
and is not hard to implement.
On Fri, Sep 12, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote:
That way we leave up to implementers to experiment with different
lengths and figure out what the optimum is
Ah, that's a good
Since when? This has been a recognized approach since people called it
hashcash ([1] - before cryptocurrencies were even invented).
I only know of one site that worked the way you propose: TicketMaster, a
long time ago. They used it as a less harsh form of blocking for IPs that
they strongly
Not to mention encrypting basically non-sensitive inter-node traffic is
almost completely worthless in providing anonymity anyway...
Recall that P2P connections carry Bloom filters too, which are not public
information.
I would be very happy if we upgraded the P2P protocol with MAC keys and a
simple home grown encryption layer, because:
1. It's practically guaranteed that 5-eyes intelligence agencies are
either systematically deanonymising Bitcoin users already (linking
transactions to real world
Misbehaving addresses can have their connecting difficulty
scaled up, which should make it uneconomic to try to DoS the usage of
Tor exit nodes for connecting to Bitcoin.
You can't solve DoS by requiring all clients to do complicated work, all
that means is that weak clients (like users
Connection rotation would be fine for improving a node's knoweldge
about available peers and making the network stronger against
partitioning.
It's also the first/next step towards decentralising the DNS seeds (for SPV
clients), as it'd allow each node to explore the network and return
Putting the efficacy of coinjoin to one side:
On Mon, Aug 11, 2014 at 1:38 PM, Tim Ruffing
tim.ruff...@mmci.uni-saarland.de wrote:
Then the only remaining reason why it could be invalid is that the input
could have
been spent already otherwise. But in this case, only one honest client with
Given that we're not running out of service bits and service bits mean you
don't have to try connecting to every node to find out what services it
supports, why not keep using the existing extension mechanism until we
start running out of bits?
Certificate validation isn't needed unless the attacker can do a direct
MITM
at connection time, which is a lot harder to maintain than injecting a
client.reconnect.
Surely the TCP connection will be reset once the route reconfiguration is
completed, either by the MITM server or by the
He wants to use it to advertise services that are not part of the P2P
protocol itself, but run on a different port. Reserving services bits
for those is not acceptable.
Why not? Does the port matter much?
All the NODE_EXT_SERVICES bit does is advertise the P2P getextsrv
command to get
I'd like to see a mechanism whereby a Bitcoin node can delegate processing
of unknown messages to an external process, so a P2P node can be composed
out of separated programs, but such a service would be indistinguishable at
the network layer from one provided by Bitcoin Core itself, so a service
Something like `getutxos` or this proposal could be implemented as an
external application or script, instead of having to integrate
everything into bitcoind.
Right, although getutxos needs access to the UTXO set which bitcoind
already has. An external plugin would have to recalculate it
Yes, that is the one change I am still pondering: adding categories
(classes), rather than one single bit.
Sure, that makes more sense I think.
As a motivating use case, Bitcoin Wallet for Android currently has a
hard-coded block explorer (biteasy.com) which it uses to find UTXOs for a
I'd be OK with such an idea if bitcoind listens on a separate port for
connections from plugins, a port that cannot be used for normal P2P
traffic. This could also be a UNIX socket instead of a TCP port.
Yes, can be done this way too. I was thinking about setups where you have
services
I just checked in a change to bitcoinj git master that makes it much easier
to create a pull tester jar. Here are instructions for how to do it.
You will need:
- A Java Development Kit (JDK), version 6 or up should work. As Java 6
was released eight years ago, this should not be a
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 do a new release where SSL is the default
soon.
No problem.
The pull tester entry point can be found here:
https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java
(nb: in the near future I will be re-namespacing the library from
com.google.bitcoin to org.bitcoinj to reflect that
The user experience of unconfirming transactions setting around in limbo
is just horrible. Bitcoin software by necessity has gotten better about
attaching fees so this sort of behavior is uncommon, but that does not
eliminate the problem.
Yes, indeed. I suspect there's a quick hack that
I suspect it is something that is going to have to be dealt with in the
future (I just don't know how yet).
The web has managed to survive despite constant fast crawls being the norm
for the past 10 years or so. I wouldn't worry too much about this unless
you can prove that a big chunk of
the memo in their transactions list
that will change.
On Wed, Jul 30, 2014 at 9:54 AM, Mark van Cuijk m...@coinqy.com wrote:
On 28 Jul 2014, at 15:32 , Mike Hearn m...@plan99.net wrote:
So what now? To be honest my next priority with BIP70 was to formalise
the extensions process, I've been
As I pointed out above, — it isn't really. Without the exit flag, I
believe no tor node will select it to exit 8333 unless manually
configured. (someone following tor more closely than I could correct
if I'm wrong here)
The exit flag doesn't mean what you would expect it to mean. The reason
On Mon, Jul 28, 2014 at 11:01 AM, Mark van Cuijk m...@coinqy.com wrote:
Good to see that it has been discussed, but I see the idea has been
postponed.
I'm not sure postponed is the right word. It wasn't in v1, but many useful
things weren't. It's more like, a bunch of people have to do work
I referred to your idea in
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04076.html
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04076.html
which
is indeed not the proposal itself.
Right, gotcha. Had forgotten about that.
Indeed
Ok... 'time' on the blockchain could be 'gamed' ... but with great
difficulty.
Unfortunately not: miners have in the past routinely gamed the timestamp in
order to use it as an extra nonce and squeeze some more gigahashes out of
their hardware/pool.
Also remember that currently the chain
Given that the speed at which the block chain advances is kind of
unpredictable, I'd think it might be better to just record the time to disk
when a PIN attempt is made and if you observe time going backwards, refuse
to allow more attempts until it's advanced past the previous attempt.
On Fri,
option, but the wallet
app already has the chain height anyway.
On Friday, July 25, 2014, Mike Hearn m...@plan99.net wrote:
Given that the speed at which the block chain advances is kind of
unpredictable, I'd think it might be better to just record the time to disk
when a PIN attempt is made
There is no infrastructure for writing block chain unit tests
unfortunately. Last time I tried to fix this I ended up going down a rabbit
hole - Bitcoin wasn't written to be a testable codebase and as a result
reinitialising it from scratch is rather difficult (there are lots of
global variables
Jeff, I think the message you're replying to got clipped.
Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a
gentlemen's agreement to postpone it as long as possible, to help make sure
the distribution of coins was as even as possible. Indeed this predated
pooled mining.
, 2014 at 12:41 PM, Mike Hearn m...@plan99.net wrote:
Jeff, I think the message you're replying to got clipped.
Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a
gentlemen's agreement to postpone it as long as possible, to help make sure
the distribution of coins
The rationale doesn't seem to apply to rule #4, what's so special about
that one?
Although I agree not having to support all of DER is nice, in practice I
think all implementations do and libraries to parse DER are widespread.
Given that the last time we modified tx rules without bumping version
, 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 with the null code point.
Python seems to have problems starting there too. It might work if we
took
using apple's
CFStringNormalize(passphrase, kCFStringNormalizationFormC);
Aaron Voisine
breadwallet.com
On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net wrote:
Yes, we know, Andreas' code is indeed doing normalisation.
However it appears the output bytes end up being different
the same result as in the test case using apple's
CFStringNormalize(passphrase, kCFStringNormalizationFormC);
Aaron Voisine
breadwallet.com
On Tue, Jul 15, 2014 at 11:20 AM, Mike Hearn m...@plan99.net wrote:
Yes, we know, Andreas' code is indeed doing normalisation.
However
Thanks Jeff.
I do feel like a lot of this is covered in the writeup I attached to the
implementation pull request, and I went over it again in the ensuing
discussion, and also in the BIP.
The discussion of how to make it secure is covered in the Upgrade section
of the writeup and in the
In particular, can this document
specifically call out that a local network attacker can MITM all the
peers.
It already does, last sentence of the authentication section is:
Querying multiple nodes and combining their answers can be a partial
solution to this, although as nothing
The request: It would be useful to limit the lifetime of a bitcoin
address.
Not only useful but essential! Otherwise mobile clients can run out of RAM
and have to cycle around and reuse addresses.
Which is indeed why BIP70 has this feature. It was thought about quite some
time ago.
[+cc aaron]
We recently added an implementation of BIP 38 (password protected private
keys) to bitcoinj. It came to my attention that the third test vector may
be broken. It gives a hex version of what the NFC normalised version of the
input string should be, but this does not match the results
On Tue, Jul 15, 2014 at 4:02 PM, Jeff Garzik jgar...@bitpay.com wrote:
BIP70 does not work well for unknown number of future payments of
unknown, unpredictable value.
You can specify zero as an output value, in which case it's the same as no
value specified. You can then just reuse the
Unicode guarantees that null-terminated strings still work.
UTF-8 guarantees that. Other encodings do not, you can have null bytes in
UTF-16 strings for example. Indeed most languages that use pascal-style
encodings internally allow null characters in strings, it's just not a good
idea to
Actually, and this is key, there _are_ reasons why deposits might not
be able to use PaymentRequests. Payments happen even when
wallets/computers are offline.
I don't understand this point. It's the *sender* that is parsing the
PaymentRequest and following the instructions. By definition
Yes, we know, Andreas' code is indeed doing normalisation.
However it appears the output bytes end up being different. What I get back
is:
cf9300*01*303430300166346139
vs
cf9300*f0*909080f09f92a9
from the spec.
I'm not sure why. It appears this is due to the character from the astral
planes.
Conceptually all transactions in the block chain lie on a single timeline.
The fact that we quantise that timeline into blocks is in many ways neither
here nor there - it's still a strict line.
What *can* happen and you must be aware of is duplicated transactions.
Satoshi sort of assumed this
Ah, that's great. Still, it would be good to be careful with the word
specification.
On Mon, Jul 14, 2014 at 1:41 PM, Wladimir laa...@gmail.com wrote:
As a loose description of the protocol for newbies it's an invaluable
resource and perhaps we should link to it from the developer guide.
just out of curiosity, do you think it will be possible to create any
other proper protocol specifications rather than the C++ original?
Well it's a finite code base so yes, it should be possible.
The only problem is so far everyone who tried it, didn't succeed :)
Heck even people who
:
https://github.com/bitcoin/bitcoin/pull/4351
BIP: 45
Title: getutxo message
Author: Mike Hearn he...@vinumeris.com
Status: Draft
Type: Standards Track
Created: 2014-06-10
Table of Contents
- Abstract
https://github.com/mikehearn/bips/commit
I took the number out, it is now just the getutxo bip until a number is
assigned.
On Thu, Jul 10, 2014 at 4:29 PM, Mike Hearn m...@plan99.net wrote:
I opened up a pull req for a draft BIP for getutxo.
https://github.com/bitcoin/bips/pull/88
I include a rendering below for your reading
On Tue, Jul 8, 2014 at 10:04 PM, Matt Whitlock b...@mattwhitlock.name
wrote:
Is anyone working on a similar specification document for Satoshi's P2P
protocol? I know how blocks and transactions are structured and verified,
but I'm interested in knowing how they're communicated over the
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 bluetooth or bluetooth connection fails for any
reason.
101 - 200 of 642 matches
Mail list logo
