On 06/01/2015 08:55 AM, Mike Hearn wrote:
Decentralization is the core of Bitcoin's security model and thus
that's what gives Bitcoin its value.
No. Usage is what gives Bitcoin value.
Nonsense.
Visa, Dollar, Euro, Yuan, Peso have usage.
The value in Bitcoin is *despite* it's far lesser usage.
On 06/02/2015 04:03 AM, Mike Hearn wrote:
1,000 *people* in control vs. 10 is two orders of
magnitude more decentralized.
Yet Bitcoin has got worse by all these metrics: there was a time
before mining pools when there were ~thousands of people mining with
their local CPUs and
On 02/14/2015 05:13 AM, Peter Todd wrote:
So stop wasting your time. Help get the consensus critical code out of
Bitcoin Core and into a stand-alone libconsensus library...
done
https://github.com/libbitcoin/libbitcoin-consensus
...
Then ... when the next time we decide to soft-fork Bitcoin
On 02/26/2015 04:30 AM, Andreas Schildbach wrote:
On 02/24/2015 11:41 AM, Mike Hearn wrote:
On 02/23/2015 04:10 PM, Eric Voskuil wrote:
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
bitcoin:3aBcD
that base58 is just
for bitcoin addresses (not true) or designed for humans... that's sort
of the point, but it's also good for URLs.
e
On 02/23/2015 09:55 PM, Eric Voskuil wrote:
Andy, adding to my previous post below:
On 02/23/2015 01:40 AM, Eric Voskuil wrote:
On 02/22/2015 11:36 PM, Andy
three values would be base58, as opposed to one
base58 and two base64url). There may be some idea that base58 is just
for bitcoin addresses (not true) or designed for humans... that's sort
of the point, but it's also good for URLs.
e
On 02/23/2015 09:55 PM, Eric Voskuil wrote:
Andy, adding
The list appears dead, this is a test.
e
signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with
bitcoin wallet can still maintain backwards compatibility.
That may be necessary depending on the implementation of existing
terminals, but I'm not familiar enough to speculate.
e
On 02/24/2015 05:14 PM, Eric Voskuil wrote:
* Add a s= parameter that uses a unique public key for each
session
Mike,
Before addressing other issues I could use some clarification on your
intent.
In one statement you refer to derivation of a session key from a bitcoin
address (passed via NFC):
doing ECDH over secp256k1 to derive a session key means we can reuse
the address that was put in the URI
On 02/23/2015 01:49 AM, Andreas Schildbach wrote:
I think at this point I'd like to bring back my original suggestion of
using DHKE (Diffie-Hellman) or simlar. I know we'd still need to
transmit some secret that could be eavesdropped,
Hi Andreas,
DHKE will not improve the situation. Either
On 02/23/2015 03:11 PM, Mike Hearn wrote:
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.
No problem, we don't all have the same context. I may have
Andy, adding to my previous post below:
On 02/23/2015 01:40 AM, Eric Voskuil wrote:
On 02/22/2015 11:36 PM, Andy Schroder wrote:
...
It's possible a really sophisticated modification could be done where
the attacker encrypts and decrypts the communication and then relays to
each party
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred.
Yes, this should be a prerequisite issue to all others.
I'd personally like to see if
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue on payment_url.
TBIP75 furthermore proposes to include an additional 'h' parameter
which would be a
One correction inline below.
e
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue on payment_url
On 02/22/2015 03:32 PM, Andy Schroder wrote:
On 02/22/2015 06:06 PM, Eric Voskuil wrote:
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
data transferred.
Yes
On 02/22/2015 03:35 PM, Andy Schroder wrote:
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only the potential
backward compat issue
:
2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org:
On 02/05/2015 04:36 PM, Martin Habovštiak wrote:
I believe, we are still talking about transactions of physical
people in physical world. So yes, it's proximity based - people
tell the words by mouth. :)
Notice from my original comment
On 02/10/2015 02:41 AM, Natanael wrote:
Den 10 feb 2015 11:34 skrev MⒶrtin HⒶboⓋštiak
martin.habovst...@gmail.com mailto:martin.habovst...@gmail.com:
Why would anyone want to do anything about payment before choosing
what he wants to buy and for what price? I've never used Amazon but
isn't
to ensure integrity and privacy. A narrow cast can use proximity to
establish trust.
2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org:
Martin,
I like your idea for the commit protocol in that it resolves the
vandalous address substitution attack. However, I don't see a way to
prevent
On 02/06/2015 12:40 AM, Andreas Schildbach wrote:
On 02/06/2015 01:36 AM, Eric Voskuil wrote:
The main advantage of BLE over BT is that it uses much less power, with
a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
be even greater and connection latency lower than BT
On 02/06/2015 12:59 AM, Roy Badami wrote:
In this case there is no need for P2P communication, just pay to an
address you already have for the other party. If you want to avoid
address reuse, use stealth addressing.
But yes, if you don't have a stealth address for the other party you can
On 02/05/2015 12:28 PM, Mike Hearn wrote:
The donation to live performer example is good - there's no issue of
accidentally paying for someone else in this context as there's only one
recipient, but many senders.
I'm not sure you could assume this, even if the payer only received one
Yes, a stellar device for mass surveillance coupled with transaction tainting.
e
On Feb 5, 2015, at 1:19 PM, Brian Hoffman brianchoff...@gmail.com wrote:
This sounds horrible. You could basically monitor anyone with a wallet in a
highly populated area and track them super easily by doing
On 02/05/2015 12:50 PM, Mike Hearn wrote:
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
BLE has an advertised range of over 100m.
http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
In the case of mass surveillance that range could most likely be extended
dramatically by the reviewer. I've seen WiFi ranges of over a mile with a
strong (not FCC approved) receiver.
WiFi
Hi Paul,
The issue is in the establishment of trust. Anyone can broadcast the initial
information.
e
On Feb 5, 2015, at 2:01 PM, Paul Puey p...@airbitz.co wrote:
The broadcast is ONLY done when the wallet is in Receive mode. Same as when
the QR code is visible. The use of the *Name*
Monkey Dude's Then I have to bother with the
address prefix, but not otherwise.
On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil e...@voskuil.org wrote:
BLE has an advertised range of over 100m.
http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
In the case of mass surveillance
. But in a bitcoin world it
would be very problematic. For this reason I wouldn't want to encourage
standardization on this approach.
e
On 02/05/2015 02:10 PM, Eric Voskuil wrote:
A MITM can receive the initial broadcast and then spoof it by jamming
the original. You then only see one.
e
On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
A BIP-70 signed payment request in the initial broadcast can resolve the
integrity issues, but because of the public nature of the broadcast
coupled with strong public identity, the privacy compromise is much
worse. Now transactions are
, William Swanson wrote:
On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil e...@voskuil.org wrote:
A MITM can receive the initial broadcast and then spoof it by jamming the
original. You then only see one.
You are right, of course. There is no way to make Bluetooth 100%
secure, since it is an over
that words match.
So the assumption is that there exists a secure (as in proximity-based)
communication channel?
e
2015-02-06 0:46 GMT+01:00 Eric Voskuil e...@voskuil.org:
On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
A BIP-70 signed payment request in the initial broadcast can resolve
Hi Andy,
This is good stuff. I've spent quite a bit of time on this question, but
set aside most of it earlier in the year in order to make some progress
in other areas. I did review what I found available at the time
pertaining to the Schildbach implementation and these questions.
Skimming the
Airbitz, and I know you guys are extremely privacy
conscious. I personally would have no problem using this feature under
certain circumstances. My question is only whether it would be wise to
standardize on the proposal as-is.
e
On Feb 5, 2015, at 3:46 PM, Eric Voskuil e...@voskuil.org
mailto:e
surface and increase the attacker's cost.
e
Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil
e...@voskuil.org napísal:
On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
That's exactly what I though when seeing the RedPhone code, but after
I studied the commit protocol I realized it's
Agree, range is not an issue. The trade-off is in battery vs. total
time, which would be influenced primarily by the battery sensitivity of
the platform. I'll send you a note to follow up.
e
On 02/05/2015 05:40 PM, Andy Schroder wrote:
Hello,
I personally would prefer as low of range as
them in the same safe, is
tantamount to having just one factor.
e
On 02/02/2015 02:54 PM, Eric Voskuil wrote:
On Feb 2, 2015, at 11:53 AM
http://airmail.calendar/2015-02-02%2011:53:00%20MST, Mike Hearn wrote:
In sending the first-signed transaction to another for second
signature, how
On Feb 2, 2015, at 11:53 AM, Mike Hearn m...@plan99.net wrote:
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
One clarification below.
e
On 02/02/2015 02:54 PM, Eric Voskuil wrote:
On Feb 2, 2015, at 11:53 AM, Mike Hearn wrote:
In sending the first-signed transaction to another for second
signature, how does the first signer authenticate to the second
without compromising the independence
On 02/02/2015 11:58 AM, Brian Erdelyi wrote:
Confusing or not, the reliance on multiple signatures as offering
greater security than single relies on the independence of multiple
secrets. If the secrets cannot be shown to retain independence in the
envisioned threat scenario (e.g. a user's
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?
Sent from my iPhone
On Feb 2, 2015, at 10:40 AM, Brian Erdelyi brian.erde...@gmail.com wrote:
Another
Confusing or not, the reliance on multiple signatures as offering greater
security than single relies on the independence of multiple secrets. If the
secrets cannot be shown to retain independence in the envisioned threat
scenario (e.g. a user's compromised operating system) then the benefit
42 matches
Mail list logo
