Yep - similarly: you live in a neighborhood with a local coffee store. Sure
you could use a stolen credit card or a fake $5 bill, but it's not worth
the risk of being caught for a $3 coffee. And on the other side, the store
can deal with 1% of transactions getting reversed or having a fake bill so
On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
Signed PGP part
On 2015-06-20 18:20, Jorge Timón wrote:
On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com
wrote:
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one
On Jun 20, 2015, at 5:27 PM, justusranv...@riseup.net wrote:
Signed PGP part
On 2015-06-20 19:19, Eric Lombrozo wrote:
On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
Signed PGP part
On 2015-06-20 18:20, Jorge Timón wrote:
On Fri, Jun 19, 2015 at 6:42 PM, Eric
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2015-06-20 19:19, Eric Lombrozo wrote:
On Jun 20, 2015, at 4:37 PM, justusranv...@riseup.net wrote:
Signed PGP part
On 2015-06-20 18:20, Jorge Timón wrote:
On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo elombr...@gmail.com
wrote:
If we
On Jun 20, 2015, at 4:47 PM, Eric Lombrozo elombr...@gmail.com wrote:
On Jun 20, 2015, at 4:16 PM, Jorge Timón jti...@jtimon.cc wrote:
On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo elombr...@gmail.com wrote:
The Bitcoin network was designed (or should be designed) with the
It seems to me that FSS RBF must enforce identical OP_RETURN data on the output
scripts as the first seen transaction, as well, to safely continue support for
various other applications built atop the blockchain.
Is there a canonical implementation of FSS RBF around somewhere I can review?
On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
If full-RBF sees any significant adoption by miners, then it will actively
harm bitcoin adoption by reducing or removing the ability for online or POS
merchants to accept bitcoin payments at all.
Retail POS merchants probably should
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
They don't need to be made cryptographically safe, they just have to be
safer than,
On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
They don't need to be made cryptographically safe, they just have to be
safer than, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.
They never will be. You can get
What retail needs is escrowed microchannel hubs (what lightning provides,
for example), which enable untrusted instant payments. Not reliance on
single-signer zeroconf transactions that can never be made safe.
On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at
wrote:
I have
It all comes down to managing risk. If you’ve got a decent risk model with
capped losses and safe recovery mechanisms…and it’s still profitable…it’s fine.
But most payment processors and merchants right now probably don’t have
particularly good risk models and are making many dangerous
I have some experience here. If you are seriously suggesting these
measures, you might as well kill retail transactions altogether.
In practice, if a retail place starts to accept bitcoin they have a
similar situation as with cash, only that the fraud potential is much
lower. (e.g. 100-dollar
On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote:
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
No worries, let me know if you have any issues. You have my phone
number.
While my own preference - and a number of other devs - is full-RBF,
either one is a good
On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote:
I just sent the following email to F2Pool:
I was disappointed to see Peter Todd claiming that you have (or will?) run
his replace-by-fee patch.
I strongly encourage you to wait until most wallet software supports
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
the full RBF is. We are going to switch to FSS RBF in a few hours.
Sorry.
On Fri, Jun 19, 2015
For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions could be for the
80% to not build on blocks containing doublespends by
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did
Extremely disappointed to hear this. This change turns double spending from
a calculable (and affordable) risk for merchant payment processors into
certain profit for scammers, and provides no useful benefit for consumers.
I sincerely hope that F2Pool reconsider, given that RBF will decrease the
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
On Fri, Jun 19, 2015 at 9:33 PM, Stephen Morse
stephencalebmo...@gmail.com wrote:
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by supporting full RBF over FSS RBF would likely be
negligible. Did they consider using FSS RBF instead?
Best,
Stephen
On Fri, Jun
On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote:
For instance, if Coinbase had
contracts with 80% of the Bitcoin hashing power to guarantee their
transactions would get mined, but 20% of the hashing power didn't sign
up, then the only way to guarantee their transactions
Chun Wang 1240902 at gmail.com writes:
Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.
FSS RBF is better than no RBF but we think it is better to use full RBF.
We think Full RBF is better for a number of reasons:
-user experience
-efficiency
-cost
-code complexity
We
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com wrote:
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 15:11, Peter Todd wrote:
If you ask me to pay you 1BTC at address A and I create tx1 that pays
1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
Yes, FSS RBF is far better.
On Fri, Jun 19, 2015 at 6:52 AM, Chun Wang 1240...@gmail.com wrote:
Before F2Pool's launch, I performed probably the only successful
bitcoin double spend in the March 2013 fork without any mining power.
[ https://bitcointalk.org/index.php?topic=152348.0 ] I know
OK, a few things here:
The Bitcoin network was designed (or should be designed) with the requirement
that it can withstand deliberate double-spend attacks that can come from
anywhere at any time…and relaxing this assumption without adequately assessing
the risk (i.e. I’ve never been hacked
On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote:
On 2015-06-19 10:39, Peter Todd wrote:
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions
with
me. This means that
Unless you're sybil attacking the network and miners, consuming valuable
resources and creating systemic risks of failure like we saw with
Chainalysis, I don't see how you're getting very small double-spend
probabilities.
So connecting to many nodes just because we can and it's not
On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd p...@petertodd.org wrote:
Having said that... honestly, zeroconf is pretty broken already. Only
with pretty heroic measures like connecting to a significant fraction of
the Bitcoin network at once, as well as connecting to getblocktemplate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 10:39, Peter Todd wrote:
Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions
with
me. This means that transactions that F2Pool has
On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote:
In that case would you enter into such contracts?
We take it as it comes.
Currently, it's perfectly possible to accept zeroconf transactions with
only a very small chance of double spend. As long as it's only possible to
Great. Thank you for this!
Adrian
On Fri, Jun 19, 2015 at 7:40 AM, Chun Wang 1240...@gmail.com wrote:
On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil adr...@coinbase.com
wrote:
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant
This is very disappointing. scorched earth replace-by-fee implemented
first at a pool, without updating wallets and merchants, is very
anti-social and increases the ability to perform Finney attacks and
double-spends.
The community is progressing more towards a safer replace-by-fee model, as
We have no contracts in place or plans to do this that I am aware of.
However, we do rely pretty heavily on zeroconf transactions for merchant
processing, so if any significant portion of the mining pools started
running your unsafe RBF patch, then we would probably need to look into
On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd wrote:
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
It is disappointing that F2Pool would enable full RBF when the safe
alternative, first-seen-safe RBF, is also available, especially since the
fees they would gain by
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 16:36, Matt Whitlock wrote:
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
I'd also like to note that prima facie doesn't mean always, it
means
that the default assumption, unless proven otherwise.
Why
prima facie generally means that in a court case the burden of proof
shifts from one party to another. For instance, if you have a federal
trademark registration that is prima fascia evidence of those rights
even though they could still be challenged. To say a prosecutor would
have prima
On Friday, 19 June 2015, at 3:53 pm, justusranv...@riseup.net wrote:
I'd also like to note that prima facie doesn't mean always, it means
that the default assumption, unless proven otherwise.
Why would you automatically assume fraud by default? Shouldn't the null
hypothesis be the default?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 16:42, Eric Lombrozo wrote:
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie”
assumptions. Otherwise, I would recommend not relying on the existence
of a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 15:37, Eric Lombrozo wrote:
OK, a few things here:
The Bitcoin network was designed (or should be designed) with the
requirement that it can withstand deliberate double-spend attacks that
can come from anywhere at any time…and
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote:
So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,
Well it is actually; that's why myself, Wladimir van der Laan, and
Gregory
On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote:
If we want a non-repudiation mechanism in the protocol, we should explicitly
define one rather than relying on “prima facie” assumptions. Otherwise, I
would recommend not relying on the existence of a signed transaction as proof
So connecting to many nodes just because we can and it's not technically
prevented is bad for the network and creating systemic risks of failure,
Well it is actually; that's why myself, Wladimir van der Laan, and
Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
If we want a non-repudiation mechanism in the protocol, we should explicitly
define one rather than relying on “prima facie” assumptions. Otherwise, I would
recommend not relying on the existence of a signed transaction as proof of
intent to pay…
On Jun 19, 2015, at 9:36 AM, Matt Whitlock
Even if you could prove intent to pay, this would be almost useless. I can
sincerely intend to do a lot of things, but this doesn't mean I'll ever
actually do them.
I am in favor of more zero-confirmation transactions being reversed /
double-spent. Bitcoin users largely still believe that
On Fri, Jun 19, 2015 at 5:42 PM, Eric Lombrozo elombr...@gmail.com wrote:
If we want a non-repudiation mechanism in the protocol, we should
explicitly define one rather than relying on “prima facie” assumptions.
Otherwise, I would recommend not relying on the existence of a signed
transaction
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 2015-06-19 17:50, Jeff Garzik wrote:
No. You cannot know which is the 'right' or wrong transaction. One tx
has
obvious nSequence adjustments, the other - the refund transaction - may
not.
I'm still not seeing a case where a node could
On Fri, Jun 19, 2015 at 9:44 AM, justusranv...@riseup.net wrote:
If we have ECDSA proof that an entity intentionally made and publicly
announced incompatible promises regarding the disposition of particular
Bitcoins under their control, then why shouldn't that be assumed to be a
fraud attempt
On Fri, Jun 19, 2015 at 10:48 AM, justusranv...@riseup.net wrote:
On 2015-06-19 17:40, Jeff Garzik wrote:
Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.
Is there not a dedicated field in a transaction (nSequence) for express
50 matches
Mail list logo
