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 elombr...@gmail.com wrote:
It seems to me we're confusing two completely different motivations for
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
Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org:
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
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
On Sun, Feb 22, 2015 at 8:11 AM, Adam Back a...@cypherspace.org 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com
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
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
Den 22 feb 2015 14:29 skrev Natanael natanae...@gmail.com:
Den 22 feb 2015 13:36 skrev Peter Todd p...@petertodd.org:
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock b...@mattwhitlock.name
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
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 we
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 successful
-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.
Den 22 feb 2015 17:00 skrev Justus Ranvier justusranv...@riseup.net:
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
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.
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 it
- Sent from my tablet
Den 22 feb 2015 17:25 skrev Justus Ranvier justusranv...@riseup.net:
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
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
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
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
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 Sunday, February 22, 2015, Peter Todd p...@petertodd.org wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com
javascript:; wrote:
In case it wasn't clear in my earlier post, there's of course a third
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
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
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 decided to
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
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.
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
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 just
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 on
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 play the
32 matches
Mail list logo
