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 wrote:
>
> Another concept...
>
> It shoul
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 red
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 of the two factors?
>
> Not sure what you mean. The idea is the second fac
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 com
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
multiple devices with the home, etc - and
needs to do this even if using a third party. On the other hand, walking
around with all necessary factors, or keeping 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, 201
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
broadca
Yes, a stellar device for mass surveillance coupled with transaction tainting.
e
> On Feb 5, 2015, at 1:19 PM, Brian Hoffman wrote:
>
> This sounds horrible. You could basically monitor anyone with a wallet in a
> highly populated area and track them super easily by doing facial
> recognitio
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 ;)
>
> Bluet
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 hots
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 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* section is speci
u?" If so, I
> send it. If there are two "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 wrote:
>> BLE has an advertised range of over 100m.
>>
>> http://www.bl
the narrow fields we are working in presently. 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 j
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 c
nario in the bitcoin model. This is also
required in order guard against repudiation (give me a signed receipt).
> On Thu, Feb 05, 2015 at 03:02:56PM -0800, William Swanson wrote:
>> On Thu, Feb 5, 2015 at 2:10 PM, Eric Voskuil wrote:
>>> A MITM can receive the initial broadcast an
g two
> messages), merchant spells four words he sees on the screen and buyer
> confirms transaction after verifying 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 :
>> On 02/05/20
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 li
pping isn't exactly flattering.
You know I love 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't trust *any* smartphone as a
platform for secure communication/data. But encrypting on the wire does
of course shrink the attack surface and increase the attacker's cost.
e
> Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil
napísal:
>> On 02/05/2015 04:04 PM, MⒶrtin H
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 po
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
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
On 02/10/2015 02:41 AM, Natanael wrote:
> Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak"
> 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 filling a form w
tin HⒶboⓋštiak wrote:
> 2015-02-06 2:29 GMT+01:00 Eric Voskuil :
>> 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
; user-friendliness.
I think for a broadcast model (e.g. Bluetooth only) that is the only
want to ensure integrity and privacy. A narrow cast can use proximity to
establish trust.
> 2015-02-10 17:55 GMT+01:00 Eric Voskuil :
>> Martin,
>>
>> I like your idea for the commit pr
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
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 th
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 wr
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 eave
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"
>>
On 02/22/2015 11:36 PM, Andy Schroder wrote:
> I agree that NFC is the best we have as far as a trust anchor that you
> are paying the right person. The thing I am worried about is the privacy
> loss that could happen if there is someone passively monitoring the
> connection.
We have the same obj
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
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 alre
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
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 rel
nJC3hVH7W6yB2Wtw24ztzGtBc4
base64url:
bitcoin:?r=bt:ABBgss5s/A3xWlhB1GI_t2NMR9Zq9E47hZOzmZ6eZTS8sbq-liugh
I prefer base58 because it's available to all bitcoin libraries, nearly
as compact as base64 (+1 byte in our example) and better standardized.
Some embedded device people might care about havi
there would be no other way to distinguish between customers
in some scenarios and this is the safest approach. We certainly won't
run out of numbers, and unused sessions can be discarded based on any
number of criteria, including discarding all but the most recent. That
may may be sufficient for you
implements to something
> more consistent?
Could you spell this out, I'm not familiar with the implementation, just
the proposals.
> Maybe we can create a new UUID for this secure service
> so Schildbach's bitcoin wallet can still maintain backwards compatibility.
That may be
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
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
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 Bitc
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 usag
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 CPU
43 matches
Mail list logo
