Nope, r1/r2 sounds good to me. BTW we should update the spec to reflect
that escaping is largely unnecessary in many cases.
--
Open source business process management suite built on Java and Eclipse
Turn processes into
I agree. It would be even sillier to start specifying container formats
for random one-off that would be kind of nice, I guess features.
No, it'd be sensible.
Here's a list I drew up a long time ago of features I imagined adding to
the payment protocol:
I'm not convinced this inversion is really a problem, but as this is quite
a complex proposal (e.g. new barcode types) the best way to move it forward
at this stage is to implement it in some existing wallets.
FWIW NFC is a lot more common than you might think. For the drive-thru case
you could
Alright. I still tend to think it's not a big deal, but there's no reason
both or all mechanisms can't co-exist.
BTW: a QR code next to a cash register can be fixed i.e. printed on paper
when using BIP70. The PoS would upload payment details to the server and
the URL for that particular PoS unit
So first bitcoind will support SPV mode then we separate the wallet?
Are the core and the wallet share any code (say, the p2p messages via
a sub-repo or something)?
bitcoind already supports SPV mode, that's how bitcoinj clients work.
However the current wallet code doesn't use it, it
From my experience the main thing people are missing with BitcoinJ is
a quick and easy way to set up a wallet as a daemon, to use the
functionality from non-java through RPC.
Yes. I'd love to have a mostly Core compatible JSON-RPC frontend. Most of
my current users are happy using it as a
Coinbase have started allowing merchants to set discounts for purchasing
with Bitcoin. Seeing an individual discount is not very motivating as they
tend to be small. Seeing them stack up over time can be more motivating
because it feels like free money. Many businesses exploit this effect with
It also seems like it would be subject to instant inflation, as it's
unprovable
The user knows the price that is on the website or menu, they know the
price they actually paid ... if the numbers don't add up that would seem to
be pretty easily detectable. But sure it's only for marketing. I
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.
Your own wallet can look up the exchange rate and compare it to what you're
getting (and
I think it should be made more clear what's the reference price for the
discount.
That might be useful for merchants that already provide a series of
price-differentiated payment methods, yes. Will think about it.
Also, currently PR are created by the payment processors afaik. How can
The issue is centralized transaction selection policies, which is
entirely orthogonal. And the solution already exists: getblocktemplate.
My (fresh!) understanding is that the reason we don't see people using
getblocktemplate to decentralise pools is because libblkmaker and other
Please, let's talk about other anti-double spend things on a separate
thread.
On Tue, Jun 17, 2014 at 5:58 PM, Isidor Zeuner cryptocurrenc...@quidecco.de
wrote:
What prevents the following steps from happening:
I linked to Satoshi's post on this earlier, he explains why it works there,
I think that's true if you assume that the instant provider list is based
on a by hand created list of accepted instant providers. That's how VISA
works now and that's why I was asking for an approach where the
trusted_instant_providers list is scalable because that seems very
dangerous.
Hi Odinn,
I think trying to incentivise nodes with money is tricky: it makes
intuitive sense but right now the market is flooded with supply relative to
demand. Yes, we worry about the falling number of nodes, but that's for
reasons that aren't really economic: the more nodes we have, the bigger
Looking good! I think this is much better than the original draft. Agree
with Andreas that supports_instant is simply equal to
(supported_instant_providers.size() 1) which makes it redundant.
Daniel is right that putting every possible provider in the Payment message
might not scale in a world
I don't see more than a bunch of accepted payment methods anywhere I
ever been in my life, I don't see merchants trusting more than a handful of
third parties.
Sure. I buy this. Although the credit card market is a great example of
what we *don't* want: a stagnant duopoly of trusted third
Mike Hearn, why don't we just have all nodes report attempted double
spends through the node network.
Please see https://github.com/bitcoin/bitcoin/pull/3883 which implements
this exact scheme. It can solve some kinds of double spends (probably), but
others - like ones done by corrupt miners
Come to think of it, is the payment protocol really the place to put this
instant provider signature
Yes it's the right place. The original attempt at this concept was in fact
called *green addresses* and the idea was you could identify a spend from a
trusted wallet by checking which keys
I read the comments on the PR. I mean no disrespect but this patch can't
prevent double spends minutes apart and a solution is as good as it's
weakest link.
Actually Tom is running a page where he shows double spends detected by his
node or relayed by mine (there are only two nodes in this
This is a cool idea, but doesn't it generate some perverse incentives? If
I'm running a full node and I want to pay CheapAir for some plane tickets,
I'll want to pay in the greatest number of individual transactions possible
Peers can calculate rewards based on number of inputs or total kb
I think many of us feel it'd be better if this kind of thing were not
needed at all, however, the best way to ensure it doesn't end up being used
is to write code, not to try and block alternative approaches. If Bitcoin
is robust the market should sort it out. If it's robust for some
transactions
On Mon, Jun 16, 2014 at 10:37 PM, Daniel Rice dr...@greenmangosystems.com
wrote:
True, that would work, but still how are you going to bootstrap the trust?
TREZOR is well known, but in a future where there could be 100 different
companies trying to release a similar product to TREZOR it seems
Yes that's true. Though it's off topic, check out
http://www.certificate-transparency.org/ it's a project to force CA's
to publish all certs they make publicly.
--
HPCC Systems Open Source Big Data Platform from
Is this any different from my bloom filter IO attack code? Nope.
It's obviously different; a thin client trying to obtain more privacy is
not attempting to deny service to anyone. You can't simply state that a
feature which uses resources for a legitimate reason is a DoS attack,
that's a
As I explained in the email you're replying to and didn't quote, bloom
filters has O(n) cost per query, so sending different bloom filters to
different peers for privacy reasons costs the network significant disk
IO resources. If I were to actually implement it it'd look like a DoS
attack on
A NODE_BLOOM service bit is a very reasonable
and simple way to do exactly that, and is defacto what implementations
that don't support bloom filters do anyway.
BTW, I find it curious that any nodes have code to disconnect peers that
send Bloom filters. It shouldn't be necessary. Bitcoinj
Hi Ron,
FYI your mail is being spamfoldered due to Yahoo's DMARC policy and the
brokenness of the SF.net mailing list software. I would not expect to get
replies reliably whilst this is the case. I think we should move away from
SF.net for hosting mailing lists personally, because it's this list
it: I'd be much more likely to run an experimental gateway in another
process on a node than experimental p2p code inside my production
bitcoinds themselves.
Yes, it's certainly better to do that during the development phase. However
if it does turn out to be good and valuable then it'd
There
is no need to have Bitcoin transport all using a single protocol, and
we can get better robustness and feature velocity if there are a
couple protocols in use (you could just run a block-transport-protocol
daemon that connects to your local node via the classic protocol).
Although
has updated its firewall blocking bitcoin sites and pools.
Whether this is simple blacklist or more sophisticated packet targeting
is uncertain, however this update did spefically target VPN handshakes.
*Sent:* Monday, April 07, 2014 at 1:07 PM
*From:* Drak d...@zikula.org
*To:* Mike Hearn m
Submitted with humility and some fear of getting laughed out of here...
Off topic aside, a bunch of us have lately started to think about the
atmosphere on this list and how to improve it. Nobody should have to fear
getting flamed or laughed at for proposing ideas, even if they turn out to
be
(sure - there are tricks to limit rates anyway, like the script in
contrib/qos, but to have it generally available the block download
needs to be more robust first)
One thing we could consider as a short term solution (if headers
first+parallel downloading will take a while, which seems
IMO this list is fine for discussing such topics.
Here are some thoughts. I had to deal with patents at Google (my name is on
a few, not my choice unfortunately). Many aspects of patent law are deeply
unintuitive, so here's the crash course as I was given it.
The first rule of patents is *you
Meh. The world is much bigger than the USA. Secondly that rule makes it
difficult to educate people about why patents are as bad as they are.
You can easily find examples that are not relevant to Bitcoin if you want
to discuss the patent system in general.
Feel free to continue censoring
Avoiding willfull infringement no longer requires paying off a
patent attorney to get a freedom to operate review. This isn't to say
that reading patents is always productive
That case raised the bar a bit, but the core problem remains - if you learn
about a patent you definitely violate
Sorry. I will never agree to the concept of a relevant idea so dangerous it
cannot be discussed. That's medieval thinking. If you would like to create
a parallel development forum where people have to swear an oath not to
think bad thoughts, go right ahead and do so.
But I'm glad to see you
My android wallet is working OK. Yes it isn't great when seeds have
temporary availability problems but things are still working.
There's a couple of pull reqs outstanding to include hard coded seed peers
and getaddr sourced IPs. Once those are finished and merged in there'll be
more backup
On Tue, May 13, 2014 at 12:40 AM, Chris Pacia ctpa...@gmail.com wrote:
Just a thought. Using the payment protocol for stealth would mean we
would likely have to return to backing up wallets all the time would it
not?
I think you are right. Awkward.
Wallets could auto-respend transactions to
Yes, bitcoinj supports and uses regtest mode. It would also have to be
changed.
You didn't provide a rationale for this. What's the cost of having them be
the same?
On Tue, May 13, 2014 at 11:45 AM, Warren Togami Jr. wtog...@gmail.comwrote:
Hi folks,
I propose changing all of the address
?
On Tue, May 13, 2014 at 12:30 AM, Mike Hearn m...@plan99.net wrote:
Yes, bitcoinj supports and uses regtest mode. It would also have to be
changed.
You didn't provide a rationale for this. What's the cost of having them
be the same?
On Tue, May 13, 2014 at 11:45 AM, Warren Togami Jr
Would it be a terrible idea to amend BIP 70 to suggest implementors
include a Access-Control-Allow-Origin: * response header for their
payment request responses? I don't think this opens up any useful attack
vectors.
It sounds OK to me, although we should all sleep on it for a bit. The
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
Ah, you're still misunderstanding my point: You can get atomicity in the
worst-case where the communications medium fails *and* stealth payments
that use up no extra space in the blockchain. This gives you the best of
both worlds.
Sounds great! How does a lightweight client identify such
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
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
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
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
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
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
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
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
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
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
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.
--
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
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
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.
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!
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
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
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
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
201 - 300 of 642 matches
Mail list logo
