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. So, in response to some of your comments below and also in
response to
Hello All,
I have updated the algorithm to include b in the derivation of a and vice
versa.
In the comment section of the gist, jhoenicke kindly pointed out that a
derivation was not including b at all, so colluding derivation was weak to
1 leaked descendant private node.
I am on my phone, but o
>> However, I don't think we should base
>> bitcoin around what Apple wants us to do. They've already had their war
>> on bitcoin. They are going to do whatever they can to protect their NFC
>> based payment system. We need to make their platform the the less
>> desirable one if they are going to p
On 02/22/2015 11:39 PM, Eric Voskuil wrote:
> The MAC address (and resource name) should be encoded using base58. This
> is shorter than base16, is often shorter than base64, better
> standardized and does not require URI encoding, and is generally
> available to implementers.
Of course this is j
On 02/23/2015 12:32 AM, Andy Schroder wrote:
> I guess we need to decide whether we want to consider NFC communication
> private or not. I don't know that I think it can be. An eavesdropper can
> place a tiny snooping device near and read the communication. If it is
> just passive, then the merchan
On 02/22/2015 11:37 PM, Andy Schroder wrote:
> Andreas and I had a number of private discussions regarding the
> payment_url parameter. I had suggested a "additional_payment_urls"
> repeated parameter, but he didn't seem to like that idea and I
> personally am indifferent, so that is why we decide
Jan, this is great stuff! Thanks for sharing your experiences.
I think the 4k payments requests issue must be solvable somehow. I had
no trouble transmitting that amount via NFC, although yes a bit of delay
was noticable.
About payment_url: Protobuf allows changing optional to repeated and yes
it
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
>>> backwar
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 transf
Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
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
Andy Schroder
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, this should be a prerequisite
On Sunday, February 22, 2015, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo > wrote:
> >In case it wasn't clear in my earlier post, there's of course a third
> >possibility - namely, some outputs are kept but n
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
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_u
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
Hello Jan,
Regarding a few of your questions:
Andreas and I had a number of private discussions regarding the
payment_url parameter. I had suggested a "additional_payment_urls"
repeated parameter, but he didn't seem to like that idea and I
personally am indifferent, so that is why we decided
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Not that issue - that's both easily avoidable, and has nothing to do with the
replace-by-fee patch. I'm talking about something in the specific patch - good
test to see if you've fully reviewed it.
On 22 February 2015 14:25:24 GMT-05:00, Tom Hard
Hi everyone,
I am working on a Bitcoin point of sale terminal based on a Raspberry Pi, which
displays QR codes, but also provides payment requests via NFC. It can optionally
receive the sender's transaction via Bluetooth, so if the sender wallet
supports it, the sender can be completely offline. O
On 2/22/2015 9:12 AM, Peter Todd wrote:
> Did you notice the even more obvious way to defeat ANYONECANPAY
> scorched earth with that patch?
Let's see. I could pay 10 people 1 BTC each with one tx, then
double-spend it with fees of 2BTC. Now at least three of the 10 have to
work together if t
On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote:
> On 2/11/2015 10:47 PM, Peter Todd wrote:
> >My replace-by-fee patch is now available for the v0.10.0rc4 release:
> >
> > https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
> >
>
> This patch immediately simplifies
- Sent from my tablet
Den 22 feb 2015 17:25 skrev "Justus Ranvier" :
>
> You just disproved your own argument.
>
> It is possible to predict risk, and therefore to price the risk.
Your fault is that you assume the predictions can be reliable and
trustable.
They can not be.
The data you have avai
On 2/11/2015 10:47 PM, Peter Todd wrote:
> My replace-by-fee patch is now available for the v0.10.0rc4 release:
>
> https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4
>
This patch immediately simplifies successful double-spends of
unconfirmed transactions. But the idea that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 10:17 AM, Natanael wrote:
> The problem with this approach is that it is worthless as a
> predictor. We aren't dealing with traffic safety and road design -
> we are dealing with adaptive attackers and malicious miners and
> pools.
>
> A
Den 22 feb 2015 17:00 skrev "Justus Ranvier" :
>
> On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> > 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
> > u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/22/2015 07:50 AM, Matt Whitlock wrote:
> 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 t
On Sun, Feb 22, 2015 at 03:18:05PM +, joli...@airmail.cc wrote:
> > Indeed, which is why I wrote some easy-to-use and highly effective
> > tools
> > to pull off double-spends and made sure to publicise them and their
> > effectiveness widely. They've had their desired effect and very few
> > p
On 2015-02-22 14:33, Peter Todd wrote:
> On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote:
>> My actual point outside of the emotive stuff (and I should've stayed
>> away from that too) is how about we explore ways to improve practical
>> security of fast confirmation transactions, and if
Den 22 feb 2015 14:29 skrev "Natanael" :
>
>
> Den 22 feb 2015 13:36 skrev "Peter Todd" :
>
> > Implementing it as a general purpose scripting language improvement has
> > a lot of advantages, not least of which is that you no longer need to
> > rely entirely on inherently unreliable P2P networking
On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote:
> My actual point outside of the emotive stuff (and I should've stayed
> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back wrote:
> away from that too) is how about we explore ways to improve practical
> security of fast confirmation transactions, and if we find something
> better, then we can help people migrate to that before deprecating the
> current weaker 0-conf transact
My actual point outside of the emotive stuff (and I should've stayed
away from that too) is how about we explore ways to improve practical
security of fast confirmation transactions, and if we find something
better, then we can help people migrate to that before deprecating the
current weaker 0-con
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock
wrote:
>On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
>> In other words, you are unprotected and potentially at greater risk
>if you
>> create a transaction depending on another zer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo
wrote:
>In case it wasn't clear in my earlier post, there's of course a third
>possibility - namely, some outputs are kept but not all. Here, it is
>generally impossible to tell whether the mo
On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote:
> In other words, you are unprotected and potentially at greater risk if you
> create a transaction depending on another zero-confirmation transaction.
This happened to one of the merchants at the Bitcoin 2013 conference in San
Jose. They s
In case it wasn't clear in my earlier post, there's of course a third
possibility - namely, some outputs are kept but not all. Here, it is
generally impossible to tell whether the motivation was fee replacement,
output replacement, or both. My proposal is to always treat these instances
as output r
Den 22 feb 2015 13:36 skrev "Peter Todd" :
> Implementing it as a general purpose scripting language improvement has
> a lot of advantages, not least of which is that you no longer need to
> rely entirely on inherently unreliable P2P networking: Promise to never
> create two signatures for a specif
On Sun, Feb 22, 2015 at 08:02:03AM +, Adam Back wrote:
FWIW I've been advocating this kind of thing in various forms for
literally years, including to hold fidelity bonded banks honest - what
you now call 'federated sidechains' - and most recently Feb 12th on
#bitcoin-dev:
19:56 < petertodd>
I should note that my proposal does require a change to the consensus
rules...but getting bitcoin to scale will require this no matter what.
- Eric Lombrozo
On Feb 22, 2015 3:41 AM, "Eric Lombrozo" wrote:
> It seems to me we're confusing two completely different motivations for
> double-spending
It seems to me we're confusing two completely different motivations for
double-spending. One is the ability to replace a fee, the other is the
ability to replace outputs.
If the double-spend were to merely add or remove inputs (but keep at least
one input in common, of course), it seems fairly saf
I agree with Mike & Jeff. Blowing up 0-confirm transactions is vandalism.
bitcoin transactions are all probabilistic. there is a small chance
1-confirm transactions can be reversed, and a different but also
usable chance that 0-confirm transactions can be reversed. I know
0-confirm is implement
40 matches
Mail list logo
