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.
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
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 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.
--
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
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.
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
[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
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:
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
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
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
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
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
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
BLE meets a different use case than regular Bluetooth. BLE is designed to
allow always-on broadcast beacons which are conceptually similar to NFC
tags, with very low power requirements. The tradeoff for this ultra-low
power consumption and always on nature is the same as with NFC tags: you
get
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
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
history. Lots of miners have dropped out due to hardware obsolescence,
yet
massive double spending hasn't happened.
How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
(https://bitcointalk.org/index.php?topic=321630.0)
Hmm. I think this
He didn't said a project for all possible language bindings, just
java bindings. Other languages' bindings would be separate projects.
Yes/no/sorta.
Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as
dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure
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,
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
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
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
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
We can certainly imagine many BIP70 extensions, but for things like
auto-filling shipping addresses, is the wallet the best place to do it? My
browser already knows how to fill out this data in credit card forms, it
would make sense to reuse that for Bitcoin.
It sounds like you want a kind of
If you're interested in working on mining decentralisation, chipping away
at getblocktemplate support would be a better path forward. It's possible
to have decentralised pooled mining - I know it sounds like a contradiction
but it's not.
I wrote about some of the things that can be done in this
You can not consider the outcome resulting by replace-by-fee fraudulent,
as it could be the world as observed by some.
Fraudulent in what sense?
If you mean the legal term, then you'd use the legal beyond reasonable
doubt test. You mined a double spend that ~everyone thinks came 5 minutes
1. They won't be attacking Bitcoin, they will attack merchants who accept
payments with 0 confirmations.
Which is basically all of them other than exchanges. Any merchant that uses
BitPay or Coinbase, for instance, or any physical shop.
If you want to play word games and redefine Bitcoin to
You can prove a doublespend instantly by showing two conflicting
transactions both signed by thar party. This pair can be distributed as a
proof of malice globally in seconds via a push messaging mechanism.
There have been lots of e-cash schemes proposed in the academic literature
that work
But, let's say, 5 years from now, some faction of miners who own
soon-to-be-obsolete equipment will decide to boost their profits with a
replace-by-fee pool and a corresponding wallet. They can market it as 1 of
10 hamburgers are free if they have 10% of the total hashpower.
Yes, like any
Are you not counting collateralized multisignature notaries? Its an
extended version of the Greenaddress.it model.
It makes unconfirmed transactions useless in the classical Bitcoin model.
Obviously if you introduce a trusted third party you can fix things, but
then you're back to having the
So you're just arguing that a notary is different to a miner, without
spelling out exactly why.
I'm afraid I still don't understand why you think notaries would build long
term businesses but miners wouldn't, in this model.
I think you are saying because notaries have identity, brand
So anyway, in my opinion, it is actually great that Bitcoin is still
relatively small: we have an opportunity to analyze and improve things.
But you seem to be hostile to people who do that (and who do not share
your opinion), which is kinda uncool.
To clarify once more, I'm all for people
I see no fundamental difference in outcome from miner collusion in
scorched-fee (which isn't guaranteed to pay the right pool!) and miner
collusion in knowingly mining a doublespend transaction.
Well, they're the same thing. Replace-by-fee *is* miner collusion in
knowingly mining a double
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
bitcoinj also uses this convention.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software
Sigh. The wallet words system is turning into kind of a mess.
I thought the word list is in fact not a fixed part of the spec, because
the entropy is a hash of the words. But perhaps I'm misunderstanding
something.
The main problem regular SPV wallets have with BIP39 is that there is no
birth
I'd like to offer that the best practice for the shared wallet use case
should be multi-device multi-sig.
Sure. But in practice people will want to have a pool of spending money
that they can spend when they are out and about, and also with one click
from their web browser on their primary
It sounds like the main issue is this is a web wallet server of some kind.
If the clients were SPV then they'd be checking their own balances and
downloading their own tx history, which would mean the coordination tasks
could be done by storing encrypted blobs on the server rather than the
server
As soon as that PaymentRequest leaves the wallet on its way to the hotel
server, it is up for grabs
Is it? I'm assuming TLS is being used here. And the hotel server also has a
copy of the PaymentRequest, as the hotel actually issued it and that's how
they're deciding the receipt is valid. So
That would be rather new and tricky legal territory.
But even putting the legal issues to one side, there are definitional
issues.
For instance if the Chainalysis nodes started following the protocol specs
better and became just regular nodes that happen to keep logs, would that
still be a
I'm not talking about keeping logs, I mean purporting to be a network
peer in order to gain a connection slot and then not behaving as one
(not relaying transactions)
That definition would include all SPV clients?
I get what you are trying to do. It just seems extremely tricky.
Hi Kalle,
I think you're thinking along the right lines, but I am skeptical that this
protocol adds much. A saved payment request is meant to be unique per
transaction e.g. because the destination address is unique for that payment
(for privacy reasons). Where would you store the signed payment
You are killing us Mike! :) We really don't like to think that BWS is
a webwallet. Note
that private keys are not stored (not even encrypted) at the server.
Sure, sorry, by web wallet I meant a blockchain.info/CoPay type setup where
the client has the private keys and signs txns, but
Don't SPV clients announce their intentions by the act of uploading a
filter?
Well they don't set NODE_NETWORK, so they don't claim to be providing
network services. But then I guess the Chainalysis nodes could easily just
clear that bit flag too.
What I'd actually like to see is for
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 have the 12 word seed be an encryption
key for a wallet backup with all associated metadata. We're heading in that
direction
Users will want to have wallets shared between devices, it's as simple as
that, especially for mobile/desktop wallets. Trying to stop them from doing
that by making things gratuitously incompatible isn't the right approach:
they'll just find workarounds or wallet apps will learn how to import
I've written a couple of blog posts on replace by fee and double spending
mitigations. They sum up the last few years (!) worth of discussions on
this list and elsewhere, from my own perspective.
I make no claim to be comprehensive or unbiased but I keep being asked
about these topics so figured
Congrats Thomas! Glad to see Electrum 2 finally launch.
* New seed derivation method (not compatible with BIP39).
Does this mean a 12 words wallet created by Electrum won't work if
imported into some other wallet that supports BIP39? Vice versa? This seems
unfortunate. I guess if seeds are
Nice, Andrew.
Just one minor point. SPV clients do not need to maintain an ever growing
list of PoW solutions. BitcoinJ uses a ring buffer with 5000 headers and
thus has O(1) disk usage. Re-orgs past the event horizon cannot be
processed but are assumed to be sufficiently rare that manual
This happened to one of the merchants at the Bitcoin 2013 conference in
San Jose. They sold some T-shirts and accepted zero-confirmation
transactions. The transactions depended on other unconfirmed transactions,
which never confirmed, so this merchant never got their money.
Beyond the fact
DHKE will not improve the situation. Either we use a simple method to
transfer a session key or a complex method.
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:
1. URIs are put in QR
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 every situation.
At the moment I'm also modifying BitPay's memo field to contain 'ack', as
Andreas' wallet otherwise reports a failure if I transmit the original via
Bluetooth. :-)
Huh?
--
Download BIRT iHub F-Type - The Free
But via Bluetooth it checks for 'ack' directly:
We need a BIP70 conformance suite really. There are so many deviations from
the spec out there already and it's brand new :(
--
Download BIRT iHub F-Type - The Free
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, and
the key within that script that it wanted to use. A
Andreas' wallet supports this, but don't do it. Payment requests can get
larger in future even without signing. Exploding the capacity of a QR code
is very easy.
Instead, take a look at the Bluetooth/NFC discussion happening in a
different thread.
On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev
I don't see how you propose to treat the bitcoin address as a secp256k1
public key, or do you mean something else?
Sorry, I skipped a step. I shouldn't make assumptions about what's obvious.
The server would provide the public key and the client would convert it to
address form then match
Hi Fikret,
This is the wrong mailing list for such questions. Most Bitcoin ATM's are
commercial products anyway and don't accept contributors. If you find one
that is different, it's better to contact them directly.
On Fri, Feb 20, 2015 at 5:19 PM, Fikret AKIN i...@fikretakin.com wrote:
Ah, I see, I didn't catch that this scheme relies on UTXO commitments
(presumably with Mark's PATRICIA tree system?).
If you're doing a binary search over block contents then does that imply
multiple protocol round trips per synced block? I'm still having trouble
visualising how this works.
This is talking about a committed bloom filter. Not a committed UTXO set.
I read the following comment to mean it requires the UTXO commitments.
Otherwise I'm not sure how you prove absence of withholding with just
current block structures+an extra filter included in the block:
but with the
So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.
This is the part where I get lost. How does this improve privacy? If I have
to specify which addresses are mine in this block, to get the tx data, the
node
Adam seems to be making sense to me. Only querying a single node when an
address in my wallet matches the block filter seems to be pretty efficient.
No, I think it's less efficient (for the client).
Quick sums: blocks with 1500 transactions in them are common today. But
Bitcoin is growing.
For downloading transactions unless you frequently receive
transactions you wont be fetching every block. Or are you assuming
bloom filters dialled up to the point of huge false positives? You
said otherwise.
Well, what I mean is, bitcoinj already gets criticised for having very low
FP
It's a straight forward idea: there is a scriptpubkey bitmap per block
which is committed. Users can request the map, and be SPV confident
that they received a faithful one. If there are hits, they can request
the block and be confident there was no censoring.
OK, I see now, thanks Gregory.
Could you maybe write a short bit of text comparing this approach to
extending BIP70 and combining it with a simple Subspace style
store-and-forward network?
--
One dashboard for servers and applications across
1. There will be a 1:1 relationship between a payment code owner and their
identity.
Bear in mind, the spec defines identity to mean:
*Identity is a particular extended public/private key pair. *
So that's not quite what is meant normally by identity. It's not a
government / real name
Hey Matt,
OK, let's get started
However, there hasnt been any discussion on this
mailing list in several years as far as I can tell.
Probably because this list is not a good place for making progress or
reaching decisions. Those are triggered by pull requests (sometimes).
If you're
The only answer to this that anyone with a clue should give is it
will very, very likely be able to support at least 1MB blocks roughly
every 10 minutes on average for the next eleven years, and it seems
likely that a block size increase of some form will happen at some point in
the next
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
I have explained why I believe there is some
These statements may even be true, but they're no logical conclusions
even if they seem obvious to you.
I don't think those claims are strictly true, specially because they
involve predictions about what people will do.
But if they're true they require some proof or at least some explanation.
The appropriate method of doing any fork, that we seem to have been
following for a long time, is to get consensus here and on IRC and on
github and *then* go pitch to the general public
So your concern is just about the ordering and process of things, and not
about the change itself?
I
Can you please elaborate on what terrible things will happen if we
don't increase the block size by winter this year?
I was referring to winter next year. 0.12 isn't scheduled until the end of
the year, according to Wladimir. I explained where this figure comes from
in this article:
If his explanation was I will change my mind after we increase block
size, I guess the community should say then we will just ignore your
nack because it makes no sense.
Oh good! We can just kick anyone out of the consensus process if we think
they make no sense.
I guess that means me and
* Though there are many proposals floating around which could
significantly decrease block propagation latency, none of them are
implemented today.
With a 20mb cap, miners still have the option of the soft limit.
I would actually be quite surprised if there were no point along the road
Alan argues that 7 tps is a couple orders of magnitude too low
By the way, just to clear this up - the real limit at the moment is more
like 3 tps, not 7.
The 7 transactions/second figure comes from calculations I did years ago,
in 2011. I did them a few months before the sendmany command was
There are certainly arguments to be made for and against all of these
proposals.
The fixed 20mb cap isn't actually my proposal at all, it is from Gavin. I
am supporting it because anything is better than nothing. Gavin originally
proposed the block size be a function of time. That got dropped, I
Looks like a neat solution, Tier.
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give
What gives Bitcoin value aren't its technical merits but the fact that
people believe in it.
Much of the belief in Bitcoin is that it has a bright future. Certainly the
huge price spikes we've seen were not triggered by equally large spikes in
usage - it's speculation on that future.
I quite
It is an argument against my admittedly vague definition of
non-controversial change.
If it's an argument against something you said, it's not a straw man, right
;)
Consensus has to be defined as agreement between a group of people. Who are
those people? If you don't know, it's impossible to
501 - 600 of 642 matches
Mail list logo
