You would only need to change it if there was a sub-satoshi hardfork,
which doesn't seem necessary anytime soon.
+
We shouldn't make any assumptions about the future price of bitcoin to make
the decision.
Hmmm ;) Didn't you just make an assumption about the future price?
This sounds
on practical/convenient QR code size?
How much of the payment protocol message size comes from use of x509?
(Just exploring what the options are).
Adam
On Thu, Mar 20, 2014 at 11:36:09AM +0100, Mike Hearn wrote:
Encoding entire payment requests into qrcodes is definitely not the way
MitM attack? Quick googling showed that SSL over bluetooth isn't
a very well developed area, and my own skills are not enough to quickly
implement a reliable secure solution here.
2014-03-20 10:36 GMT+00:00 Mike Hearn m...@plan99.net:
Encoding entire payment requests into qrcodes is definitely
On Fri, Mar 21, 2014 at 11:59 AM, Adam Back a...@cypherspace.org wrote:
Maybe its time to explore raw ECDSA signed message based certs.
If you want to create and run a new CA, by all means. But I bet you don't.
So we're stuck with the current system for now.
btw I dont think its quite 4kB.
Sounds very relevant to what we were just discussing on the other thread,
about securing Bluetooth connections and BIP70.
On Fri, Mar 21, 2014 at 11:58 AM, Andreas Schildbach
andr...@schildbach.dewrote:
Access granted. Welcome! (-:
On 03/21/2014 10:11 AM, Chris D'Costa wrote:
Hello
I
Oh, one other reason I found - apparently RIM, at least in the past, has
been telling CA's that they need to pay mad bux for the Certicom ECC
patents. So that's another reason why most certs are still using RSA.
On Fri, Mar 21, 2014 at 12:08 PM, Mike Hearn m...@plan99.net wrote:
On Fri, Mar 21
+0100, Mike Hearn wrote:
Oh, one other reason I found - apparently RIM, at least in the past,
has been telling CA's that they need to pay mad bux for the Certicom
ECC patents. So that's another reason why most certs are still using
RSA
SPDY requires SSL and is even more complex than HTTP.
Really, the current protocol we've got (length prefixed protobufs) is just
fine except for the lack of encryption/authentication. For that you need to
do ECDH to establish a shared AES session key, and MAC each packet. Like I
said, it's not
Those locations are completely unsuitable to bitcoin transactions,
since the receiver cannot verify double-spending or anything else
about the transaction.
The usual issue is that they lack internet *for some customers*. The place
may well have private wifi or hardwired connections that
In case you didn't see this yet,
http://gavintech.blogspot.ch/2014/03/it-aint-me-ive-got-pgp-imposter.html
If you're using PGP to verify Bitcoin downloads, it's very important that
you check you are using the right key. Someone seems to be creating fake
PGP keys that are used to sign popular
I think it's mostly a UI issue. The recipient needs to understand that what
he received is nothing more than an IOU that can be revoked at any time. If
the UI makes it clear and the user trusts the sender, no problem. BIP70
would work as before.
On Sat, Mar 22, 2014 at 6:24 PM, Jeff Garzik
A few months ago I had a conversation with an executive at a Bitcoin
company, and I suggested their developers should get involved with the
development list. I was told that they are all subscribed but refuse to
post. Puzzled, I asked why, maybe the process isn't clear or we didn't talk
about what
Hey Addy,
I am seeing a big drop in reachable nodes on
http://getaddr.bitnodes.io/dashboard/ starting from about March 25th 7:20pm
and coming back 9:35pm. Is this a glitch in the monitoring system or did
some real network event happen then?
Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot of interoperability between
wallets with regards to
Yeah, for those cases we'd need to think of something else. That gets into
the realm of creating our own infrastructure though ...
--
___
Bitcoin-development mailing list
On 26.03.2014, at 21:49, Mike Hearn m...@plan99.net wrote:
Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
our BIP32 wallet structures would be compatible - and I discovered that
only I was planning to use the default structure.
Because I'm hopeful that we can get a lot
But these cases are the norm, rather than the exception.
Well, you're lucky, you live in Berlin. Most of the payments I make with
Bitcoin are online, to websites. So this will differ between people.
I wonder how critical it is. Let's say you are paying for a meal. In your
head the place
One issue that I have is bandwidth: Electrum (and mycelium) cannot
watch as many addresses as they want, because this will create too
much traffic on the servers. (especially when servers send utxo merkle
proofs for each address, which is not the case yet, but is planned)
This is surprising
By the way, I just noticed that greenaddress.it is creating seeds that have
24 words instead of 12. Does anyone know what's up with that? They claim to
be using BIP32 wallets so I wanted to see if they were using the default
structure and if so, whether bitcoinj was compatible with it (before I
.
On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn m...@plan99.net wrote:
Ah, BIP32 allows for a range of entropy sizes and it so happens that they
picked 256 bits instead of 128 bits.
I'd have thought that there is a right answer for this. 2^128 should not
be brute forceable, and longer sizes have
To be honest, I have not carried out a comprehensive examination of
server performance. What I can see is that Electrum servers are often
slowed down when a wallet with a large number (thousands) of addresses
shows up, and this is caused by disk seeks (especially on my slow VPS).
Yes that
(the number of days since the genesis
block) to help wallet restore but that is SPV specific.
On Thu, Mar 27, 2014, at 01:49 PM, Thomas Voegtlin wrote:
Le 27/03/2014 13:49, Mike Hearn a écrit :
IP32 allows for a range of entropy sizes and it so happens that
they picked 256 bits instead
Modern devices like smartphones and tablets do not have swap files. This
design is chosen to ensure responsive, fluid UI that can avoid blocking on
disk regardless of how much multi-tasking is done, but it creates ripples
that impact everything else.
One implication of this is that on these
I don't want to manage a business relationship with every shop I buy
something from. That's way too much effort. There can certainly be cases
where a more complicated relationship is created by bootstrapping off
BIP70, perhaps with an extension, but nailing the ordinary buyer-to-seller
What is too abstract in a contact list ? If the payment comes with a tag
like refund the UI could display as such and if it comes with e.g. VAT then
that.
How is this any different? The tag in this case is the address and the
payment is being delivered by the block chain (direct submission
It is not more effort than an auto remembered call-in phone number. You
delete if you do not care. The difference however is that it would be a
clean protocol for repeated payments in both directions for whatever
reason, where refund is and payment are not special compared to 1st
So I take it BOPShop won't be supporting BIP70 then? :(
On Fri, Mar 28, 2014 at 3:27 PM, Tamas Blummer ta...@bitsofproof.comwrote:
I have nothing against incremental development. This will however not pick
up until it offers some incremental benefit compared to current payment
processor
Supporting BIP70 by BitPay or BopShop is a cake since it does no more then
they did without it.
I am not in opposition but see no reason to be enthusiastic about it. I
will once the spec goes
further than what was possible before.
So, if e.g. Trezor ships a firmware update that uses BIP70
Yeah. Though there's actually a proposal for recurring payments from the
KillBill folks. I keep bugging BitPay to review it but it seems they're
lagging behind there, so perhaps we should just move ahead with that
candidate extension.
On Fri, Mar 28, 2014 at 3:01 PM, Gavin Andresen
On 28/03/2014 17:59, Andreas Schildbach wrote:
Ok, why don't fix this in the spec for now, by defining a fixed expiry
time. In the EU, most products are covered by a 2 years warranty, so it
seems appropriate to pick 2.5 years (30 months) -- allowing for some
time to ship the product back and
They would just encode the OP_RETURN script into an Output structure. I'm
not sure about the question - you seem to give the answer yourself in the
first paragraph?
--
___
Right - the explanation in the BIP about the board of directors is IMO a
little misleading. The problem is with splitting a private key is that at
some point, *someone* has to get the full private key back and they can
then just remember the private key to undo the system. CHECKMULTISIG avoids
Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If
you have a use for a new type of script it can be added, and people do
upgrade:
http://getaddr.bitnodes.io/dashboard/chart/?days=30
As you can see the 0.9 rollout is going OK. If a new script type had been
made standard for
Ranvier justusranv...@gmail.comwrote:
On 03/29/2014 01:30 PM, Mike Hearn wrote:
They would just encode the OP_RETURN script into an Output structure. I'm
not sure about the question - you seem to give the answer yourself in the
first paragraph?
I guess what I was asking is whether
This proposal will destroy Bitcoin. I would expect nothing less coming from
a Google employee.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
payments to be made
to the wrong party? Of course-- but that's already true. And that's not
something BIP70 solves (or attempts to solve) either.
(To explain [better than I could] why I feel PKI is a pragmatic solution,
I defer to Mike Hearn 's article:
https://medium.com/bitcoin-security
This comes up every few months. I think the problem you are trying to solve
is already solved by SSL client certificates, and if you want to help make
them more widespread the programs you need to upgrade are web browsers and
not Bitcoin wallets. There are certainly bits of infrastructure you
On Fri, Apr 4, 2014 at 3:22 PM, Eric Larchevêque ela...@gmail.com wrote:
I see only benefits for the entire ecosystem, and if I'm working on such a
proposition it is because I really need this feature.
Why do you need it? Because you don't want to implement a login system?
Very, very few
What if I do a shared spend/CoinJoin type tx? Now anyone who took part in
the shared tx with me can get into my hotel room too?
Oh, if these seem too abstract, also consider bitbanks. In an ideal world
nobody would outsource running of their Bitcoin wallet, but sadly people
do, so then they
Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins then
we have a problem :) But regardless, actually like I said, you don't need a
plugin. Browsers do it all already. With the keygen tag they even create
a private key and upload the public part to be signed for you, it's
In my opinion, the number of full nodes doesn't matter (as long as
it's enough to satisfy demand by other nodes).
Correct. Still, a high number of nodes has a few other benefits:
1) The more nodes there are, the cheaper it should be to run each one,
given that the bandwidth and CPU for
My guess is that a large number of users have lost interest after they
lost their money in MtGox. The 24th of February coincides with the
final shutdown
Sigh. It would not be surprising if MtGox has indeed dealt the community a
critical blow in this regard. TX traffic is down since then too:
with another.
Eric Martindale
Developer Evangelist, BitPay
+1 (919) 374-2020
On Apr 7, 2014 7:05 AM, Mike Hearn m...@plan99.net wrote:
My guess is that a large number of users have lost interest after they
lost their money in MtGox. The 24th of February coincides with the
final shutdown
It uses ~no electricity, it's not like mining.
The primary resources it needs are disk space and bandwidth, after an
intensive initial day or two of building the database.
Actually, I wonder if we should start shipping (auditable) pre-baked
databases calculated up to the last checkpoint so
* Sent 456.5 gb data
At my geographic service location (Singapore), this cost about $90 last
month for bandwidth alone.
One of the reasons I initiated the (now stalled) PayFile project was in
anticipation of this problem:
https://github.com/mikehearn/PayFile
Multi-sig requires infrastructure. It isn't a magic wand that we can
wave to make everyone secure. The protocols and techniques necessary
don't exist yet, and apparently no one has much of an incentive to
create them.
It is starting to happen. If you're OK with using a specific web wallet
I'd be careful with swift generalisations. It depends a lot on the value of
your product. I didn't have any hangups about installing a plugin to use my
TREZOR: compared to the cost and effort involved with the rest of it,
installing a plugin was by far the easiest part.
Another example. Back in
The right way to start with this, if anyone cares, is to add
instrumentation to existing SPV wallet apps to report back to home base how
long they are running for, how much disk space / RAM they have, and
possibly what kind of hardware.
I *strongly* suspect that the vast majority of SPV wallets
I tend to agree with slush here - counting the IPs in addr broadcasts often
gives a number like 100,000 vs just 10,000 for actually reachable nodes (or
less). It seems like optimising the NAT tunneling code would help. Starting
by adding more diagnostic stuff to the GUI. STUN support may also
. This is why, given the tiny size
of the bitcoin core development team, I do not think it makes sense to
spend precious coding hours chasing this goal.
On 10 Apr 2014 08:51, Wladimir laa...@gmail.com wrote:
On Thu, Apr 10, 2014 at 8:38 AM, Mike Hearn m...@plan99.net wrote:
I tend to agree
I find it is odd that we who hold the key to instant machine to machine
micro payments do not use it to incentivise committing resources to the
network.
It's not a new idea, obviously, but there are some practical consequences:
1) To pay a node for serving, you have to have bitcoins. To get
1) There is no catch 22 as there are plenty of ways getting bitcoin
without bootstrapping a full node.
I think I maybe wasn't clear. To spend coins you need transaction data.
Today, the dominant model is that people get that data by scanning the
block chain. If you can obtain the transaction
What would this involve?
Do you know of any previous work towards this?
Chain pruning is a fairly complicated project, partly because it spans
codebases. For instance if you try and implement it *just* by changing
Bitcoin Core, you will break all the SPV clients based on bitcoinj (i.e.
all
Chain pruning is probably a separate thread, changing subject.
Reason is that the actual blocks available are likely to change frequently
(if
you keep the last week of blocks
I doubt anyone would specify blocks to keep in terms of time. More likely
it'd be in terms of megabytes, as that's
Oh yeah, credit goes to Mike Hearn for the payment channels, and if I'm
correct, for the hub concept as well.
Actually, the design is from Satoshi and Matt did most of the
implementation work last year during a Google internship. Though I ended up
doing a lot of work on it too. We actually
Suggestions always welcome!
The main problem with this is that the block chain is mostly random bytes
(hashes, keys) so it doesn't compress that well. It compresses a bit, but
not enough to change the fundamental physics.
However, that does not mean the entire chain has to be stored on expensive
That's so weird, though, because we haven't been able to get anything to
accept the transaction, seemingly, and yet it was accepted into the block
chain 15 blocks ago.
If the tx is already in the block chain then it won't be accepted again,
because it would be double spending itself!
2) If I wanted to measure validation performance, to get the number of
peak tps that could be processed without taking block sides or network
latency into account, how would I do that? Has anybody tried this
before?
You can just reindex/replay the chain. It's been done many times.
Pieter tried it already. If the two nodes views of each others mempools are
not exactly in alignment it ends up being slower than just sending the data
immediately and redundantly.
On Mon, Apr 21, 2014 at 6:38 PM, Mark Friedenbach m...@monetize.io wrote:
Yes, it certainly can be improved in
Lately someone launched Finney attacks as a service (BitUndo). As a
reminder for newcomers, Finney attacks are where a miner secretly works on
a block containing a double spend. When they eventually find a block, they
run to the merchant and pay, then broadcast the block. In a simpler variant
of
Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and commented upon using nothing more
than a web browser.
I don't think Twitter is an appropriate medium for discussing the details
of byzantine consensus algorithms.
I'm not going to bother
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
Hm? I didn't think this is at all what they did. What they claim to
do is to prioritize transactions in their mempool from people who pay
them
That's the definition of a Finney attack, right? A tx is broadcast and
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote:
Right, this works in the Bitcoin network today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction.
Yes, but that can be fixed with
Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:
1. The bitcoinj API already lets you create and use multiple wallets.
What's more, because of the desire to do key rotation (think rotating
On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell gmaxw...@gmail.comwrote:
This is not voting.
It absolutely is! It was widely discussed as such at the time, here is a
thread where people ask how to vote and the operator of Eclipse said he was
removing his vote for P2SH:
Yes, you can reorg out the blocks and actually remove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.
Well, my original thought
On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón jti...@monetize.io wrote:
I'm using it in the same sense Satoshi used it. Honest miners work to
prevent double spends. That's the entire justification for their
existence.
I thought the mechanism they used to prevent double-spends was proof of
Am I missing something?
The scheme you described does nothing about Finney attacks, which is the
issue presently faced.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo
This scheme would discourage people from attempting a Finney attack
because they would end up worse off if they did.
Phrased another way, it simply makes every block a Finney attack that
charges the maximum double spending fee possible. This doesn't solve the
problem.
Beyond needing to double
Like I said before, that leads to the obvious next step of
deleting/stealing their coinbases if they don't identify themselves.
And as I said before, that's a huge leap. A majority of miners deciding
double spending needs tougher enforcement doesn't imply they also think all
miners should
And that's achieved through proof of work, not through miner's honesty.
You can't disentangle the two. Proof of work just makes a block chain hard
to tamper with. What it contains is arbitrary. Honest miners build a block
chain that's intended to stop double spending. Dishonest miners don't.
Thanks Sergio!
On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner sergioler...@certimix.comwrote:
For more information you can check my post:
http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows
100 tps and
Of course if we're not comparing this with Bitcoin today and we're
comparing it to some theoretical mechanism for instant p2p
serialization without requiring proof of work then, yes, this concept
is not very interesting.
Bitcoin's competition is not some theoretical perfect p2p system but
Casting that vote does them no harm.
Every time another pool joins the blacklist, there's no harm to them to
doing so. At some point they will reach a majority
These statements do not follow from each other.
--
Proving that you can convince the economic majority that the
interpretation of existing blocks is in any way up for grabs would set a
dangerous precedent, and shake some people's faith in Bitcoin's overall
robustness and security (well, mine anyway.)
Hmm, then I think your faith needs to be
You don't get any money back, but you do get an angry shopkeeper chasing
you down the street / calling the police / blacklisting you from the
store.
If they could do that they'd just take the stolen property back and you
would have failed to spend your money twice. So this is by definition,
When you have a *bitcoin* TXn buried under 100 blocks you can be damn
sure that money is yours - but only because the rules for interpreting
data in the blockchain are publicly documented and (hopefully)
immutable. If they're mutable then the PoW alone gives me no confidence
that the money
I generally agree, but I wonder how popular cloning wallets between devices
will be in future. Right now if someone wants to have a wallet shared
between Hive, blockchain.info and Bitcoin Wallet for Android, we just tell
them they're out of luck and they need to pick one, or split their funds up
I'm not sure I understand why you need any special structure for this at
all. The way I'd do it is just use regular HD wallets for everyone, of the
regular form, and then swap the watching keys. Why do people need to be
given a cosigner index at all, given that they all have unique root keys
PaymentRequests are limited to 50,000 bytes. I can't think of a reason why
Payment messages would need to be any bigger than that. Submit a pull
request to the existing BIP.
In future it might be nice to have images and things in the payment
requests, to make UIs look prettier. But with the
What stops the buyer just always waiting to get their money back?
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet -
Please be aware that your emails are being spamfoldered by Gmail. This is
because Yahoo has enabled DMARC enforcement for mail sent from Yahoo and
that renders it incompatible with Sourceforge mailing lists.
There are two fixes:
1) Don't use Yahoo.
2) The real fix which is, we should stop using
Note how the mechanism I'm proposing is basically just a Jeremy
Spilman-style micropayment channel(1) used for a single payment; I
should have made that clear in my original post.
Right, that does make more sense. Yes, it's a good idea. The question is
whether wallet UI's can support it
Bitcoin is not a vendor, so I doubt that would work.
I doubt we should spend any time on this. The chance of a string collision
is extremely low. The current mime types are fine.
On Sat, Apr 26, 2014 at 10:15 PM, Ross Nicoll j...@jrn.me.uk wrote:
Dear all,
Still going through the payment
Let's assume we use one shared branch for everyone. Then two cosigners
could need a new receiving address at the same time, and get the next
unused address on that branch.
This is the part I struggle to understand. There is no shared branch
because each user/cosigner has their own unique seed
Ah, I see now. Thanks. And actually now I re-read it, Manuel's explanation
was clear, it just didn't sink in for some reason.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with
That moves us away from a pure trustless system built upon a small
democratic foundation (as something of a necessary evil in an imperfect
world where humans run our computers and use our system) and toward a
democratic system.
You don't have to agree, but I hope you can understand the
Who cares what it is? Setting to an empty byte array is fine, IMO. The
payment protocol is already rolling out. It's implemented in several
wallets, BitPay implements it, Coinbase is implementing it, etc.
-10 for changing such a basic thing at this point. It'd cause chaos for
the early
Looks good to me!
You're not in the DNS seeds yet. If you leave your nodes up for a while
then you'll start getting traffic from bitcoinj clients too.
On Tue, Apr 29, 2014 at 10:13 AM, Eugen Leitl eu...@leitl.org wrote:
I've put up some bitcoind nodes after the network is
in need of some,
I do think we need to move beyond this idea of Bitcoin being some kind of
elegant embodiment of natural mathematical law. It just ain't so.
Every time miners and nodes ignore a block that creates formula() coins
that's a majority vote on a controversial political matter, as evidenced by
the
These parties wouldn't generally consider themselves attackers
Of course not, attackers rarely do :)
But they are miners who are taking part in malicious double spending. That
makes them attackers. If miners don't exist to stop double spending, what
do they exist for?
I mean, this is
I think we're going around in circles here so this will be my last message
on the thread unless someone comes up with something new.
On Wed, Apr 30, 2014 at 3:12 PM, Gareth Williams gac...@gmail.com wrote:
If Bitcoin works correctly nobody should have to care if they consider
themselves
A bunch of different people either have implemented or are implementing
BIP70 at the moment. Here's a bunch of things I've been telling people in
response to questions. At some point I'll submit a pull req with this stuff
in but for now it's just an email.
*Error handling during signature
Although I agree 32 bits for a version is overkill, I really don't like the
idea of you simply ignoring the protocol spec to try and reduce your own
costs. Especially because in future we should make unknown versions a
validation rule, so we can easily trigger hard forks.
If this change was
Really nice! We definitely need to put together a team who really cares
about the operations side of the network and this is a fantastic start.
It'd be nice if you didn't assume knowledge of what statsd is out of the
box. Given the name I'd assumed it was a small UNIX daemon but it seems
it's
It looks like the packet format statsd expects is rather simple - it should
be easy to experiment with.
Perhaps a good next step would be to improve your patch so that someone can
get a feed of the stats packets via TCP by e.g. ssh tunnelling to their
host. Once it's easy to get a feed of simple
I think there a few different possible ways to go here.
One is to try and simplify the setup of all the components so it all gets
installed together. That might be feasible in some quite restricted setups
but the installation instructions for Graphite look kind of terrifying.
Another is to
In a way it looks similar to how the Bitcoin DNS seeds work, trying to
find good and stable nodes, although more extensive.
Yeah, it's somewhat similar, except that Tor directory authorities are
authenticated (the public keys are in the source code), whereas DNS seeds
aren't. Also Bitcoin
I wrote an article about an ECDH extension for BIP 70:
https://medium.com/p/cb2f81962c1b
The article is meant for people who don't follow bitcoin-development so
I'll summarise it here:
- The notion of being able to publish a piece of data once and use it to
receive lots of payments
Of course we quickly rejected the idea of depending solely on a
communications backchannel to retrieve funds. Any communications medium
that isn't the blockchain makes the payment non-atomic
Yes, I know you rejected this design, which is why I'm now proposing it
instead. I think you made the
301 - 400 of 642 matches
Mail list logo
