[Bitcoin-development] IMPORTANT - Bitcoin Dev List Move Tuesday, June 23rd 8pm UTC

[Warren Togami Jr.]

This is an important notice to all members of the Bitcoin Dev List.


*Tuesday, June 23rd 8pm UTC (1pm PDT) the following will happen.*

   - The current list at bitcoin-development@lists.sourceforge.net will
   reject all posts.
   - The current archives at
   http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/ will be
   exported.
   - The test archives at the new list will be wiped and replaced with an
   import from the old list.
   - The new list
   https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev will be
   open to posts after the archive import is complete.

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Everyone may to subscribe at the new list now.  Feel free to make test
posts.   Anything posted prior to the switchover on Tuesday will be wiped
from the archives.

*DMARC Status*
A current issue with this list is posts from domains that require DKIM
signature verification will end up in the spam folder at popular providers
like gmail.  Initially the new list will have that exact same problem as we
will continue to have the subject tag and footer.  Within a few weeks LF
will upgrade Mailman to do automatic Munge From
 which will solve this problem.

Warren Togami
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?

[Jonas Schnelli]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 > m / purpose' / network' / asset_type' / account' / change / index
> 
> ...
> 
> I was also wondering if anyone had previously suggested something 
> similar that I missed when cruising the mailing list archives on
> the subject.


Hi Matt

a)
In my opinion, HD chain standards like Bip43/44 are there to allow
users to use different wallets with the same seed/wordlist (switch
over or use in parallel).
In practice, wallet re-importing / re-creating is not trivial and has
risks of missing out spent or spendable coins.
Take the current landscape. Electrum doesn’t follow the Bip39 standard
[1]. Breadwallet does not support Bip44 [2].
If users start to think, as long as they keep the Bip39 wordlist save,
nothing can happen, is a material fallacy (and i see a trend into this
direction).
A hd seed will not recover your non-blockchain-metadata. HD seed
recovery is a disaster recovery method.

Because of that I am unsure if standards of hd chainstructurs does lead
users and developers into the right directions.
In my opinion, reimporting a hd seed is a experts feature that requires
manual configuration.


b)
Creating deep level chains like m/a/b/c/d/e/f/g/h requires more cpu
power to derive private key with a given seed or wordlist.
If you are using hardware wallets like Trezor or Digitalbitbox, you
probably feel the required time when signing/deriving.

[1] https://bitcointalk.org/index.php?topic=1082586.0
[2] https://github.com/voisine/breadwallet/issues/131


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVhTxdAAoJECnUvLZBb1Ps7HIP/00wqG9uEDGE77S6QsSmWWWm
OHYSlWzSeFURnkWyH4B1pcyGL9JxkHJMqmiHr5aBGIt0WGM8S1xwFImg7aFeWe8B
s5tjT80QwH6/RrGnrIFwdJp4QdAriVq7G0lfexika8O8LxW45LzP7BTQ1SoFVZ5o
mQuEzLG3A+NaKREqUMXBiSWAAuM9m08GBcRGsqd9tpvUUxqiJFHAbKqn2yVtuR3h
f+wJeQyjUf6ZqkIDor73lyjay6YpDyYveHaIxP9WfKJGvEVCVisuOXx0C3C7u5ps
SF1p2xCQUEC1xRVHySBgr0VdTYQlMpSVg7XOWSPRPXjfyBBwGW9aLZyGuDDTe0ca
Wa+u3CNRg3wIwsp3gG15wWK/M2eFPMKNwlE0DqSP9Siin0QlLRcuRe39D5BSjcsQ
xfQXNEf2gA0C7rMGA47K5fmxnB4qukkM8UqrOSqtczUO2AP1vdhhwJRi+/Cq9l1r
i1isL4cncwtf3/z965eN9vvou+a1dgU9L2gONmHp5eHwOtPh83u8BXEUof+VMUrN
B+vLHJMRRMucyASlehmzGe8EJiJ3Hlo4NjVpTNg/V8bnHY59lpm6GylvCa7YjR/d
xWB6jmG/7nqyRrJ0byIdZRGLtr/LuleIoFCwPUAO1jR4x626h0iVo82wPBPQXAJ1
IhkX/FW90s9i8vErMjwf
=To1w
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Ivan Brightly]

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
they don't change their procedures.

Perfection is not necessary in all situations.

On Sat, Jun 20, 2015 at 12:02 AM, Eric Lombrozo  wrote:

>
> > On Jun 19, 2015, at 8:48 PM, Luke Dashjr  wrote:
> >
> > 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 a decent rate of success merely by
> making one
> > transaction propagate fast (eg, 1 input, 1 output) and the other slow
> (eg,
> > 1000 inputs, 1000 outputs) and choosing your peers carefully. The only
> reason
> > unconfirmed transactions aren't double spent today is because nobody is
> > seriously *trying*.
> >
> > Luke
> >
>
>
> Newspapers are often sold in vending machines that make it possible for
> anyone to just pay the price of one and take them all…and most of the time
> they are not that carefully monitored. Why? Because most people have better
> things to do than try to steal a few newspapers. They probably were much
> more closely monitored earlier in their history…but once it became clear
> that despite the obvious attack vector very few people actually try to game
> it, vendors figured it wasn’t really that big a risk. Same thing applies to
> people trying to steal a piece of bubble gum at the cash register at a
> convenience store by double-spending.
>
> - Eric Lombrozo
>
> >
> --
> > ___
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Hard fork via miner vote

[Pieter Wuille]

Hello all,

I've seen ideas around hard fork proposals that involve a block version
vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
believe this is a bad idea, independent of what the hard fork itself is.

Ultimately, the purpose of a hard fork is asking the whole community to
change their full nodes to new code. The purpose of the trigger mechanism
is to establish when that has happened.

Using a 95% threshold, implies the fork can happen when at least 5% of
miners have not upgraded, which implies some full nodes have not (as miners
are nodes), and in addition, means the old chain can keep growing too,
confusing old non-miner nodes as well.

Ideally, the fork should be scheduled when one is certain nodes will have
upgraded, and the risk for a fork will be gone. If everyone has upgraded,
no vote is necessary, and if nodes have not, it remains risky to fork them
off.

I understand that, in order to keep humans in the loop, you want an
observable trigger mechanism, and a hashrate vote is an easy way to do
this. But at least, use a minimum timestamp you believe to be reasonable
for upgrade, and a 100% threshold afterwards. Anything else guarantees that
your forking change happens *knowingly* before the risk is gone.

You may argue that miners would be asked to - and have it in their best
interest - to not actually make blocks that violate the changed rule before
they are reasonably sure that everyone has upgraded. That is possible, but
it does not gain you anything over just using a 100% threshold, as how
would they be reasonably sure everyone has upgraded, while blocks creater
by non-upgraded miners are still being created?

TL;DR: use a timestamp switchover for a hard fork, or add a block voting
threshold as a means to keep humans in the loop, but if you do, use 100% as
threshold.

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[David Vorick]

I see it as unreasonable to expect all nodes to upgrade during a hardfork.
If you are intentionally waiting for that to happen, it's possible for an
extreme minority of nodes to hold the rest of the network hostage by simply
refusing to upgrade. However you want nodes to be able to protest until it
is clear that they have lost the battle without being at risk of getting
hardforked out of the network unexpectedly.

I think it makes sense to add a second fuse. After the 95% barrier has been
crossed, a 6 week timer starts that gives the remaining 5% time to upgrade.
If they still don't upgrade, they have intentionally forked themselves from
the network and it is not something that the remaining 95% need to be
concerned with.

On Sat, Jun 20, 2015 at 1:13 PM, Pieter Wuille 
wrote:

> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] F2Pool has enabled full replace-by-fee

[Cameron Hejazi]

On Saturday, June 20, 2015, Ivan Brightly > wrote:

> 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 they don't change their procedures.
>

These analogies being brought are based on the goal of quick
payments, which is different from the goal of Bitcoin:
cryptographically sound, distributed consensus.



> Perfection is not necessary in all situations.
>

If you want zeroconf transactions, first realize that this goal currently
has no sound solution in Bitcoin and until it does, supporting it should
not be a part of the agenda. There are two paths going forward, not
independent of one another, that would achieve the goal of quick payments
for your coffee etc:
- Research/implement a solution that is consistent with the goal of Bitcoin
- Rely on a cosigning central authority

If you think the latter option is nasty, remember that people,
like corporations, can be nasty as well. Do not rely on the good faith of
people.

Cameron
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[Tier Nolan]

I agree giving notice that the change is going to happen is critical for a
hard fork.  If miners vote in favor, they need to give people time to
upgrade (or to decide to reject the fork).

The BIP 100 proposal is that no change will happen until a timestamp is
reached.  It isn't clear exactly how it would work.

Testnet: Sep 1st 2015
Mainnet: Jan 11th 2016

It suggests 90% of 12000 blocks (~83 days).

This means that if 10800 of the last 12000 blocks are the updated version,
then the change is considered locked in.

I think having an earlier "fail" threshold would be a good idea too.  This
guarantees notice.

Assuming 3 is  and 4 is 

If the median of 11 timestamp is after 1st Sep 2015 and less than 10800 of
the last 12000 blocks are version 4+, then reject version 4 blocks
If the median of 11 timestamp is after 1st Nov 2015 and at least 10800 of
the last 12000 blocks are version 4+, then reject version 3 blocks
(lock-in)
If the median of 11 timestamp is after 1st Jan 2016 and at least 10800 of
the last 12000 blocks are version 4+, the allow 

This means that if the 90% threshold is lost at any time between 1st Sep
and 1st Nov, then the fork is rejected.  Otherwise, after the 1st Nov, it
is locked in, but the new rules don't activate until 1st Jan.

For block size, miners could still soft fork back to 1MB after 1st Nov, it
there is a user/merchant revolt (maybe that would be version 5 blocks).


On Sat, Jun 20, 2015 at 6:13 PM, Pieter Wuille 
wrote:

> Hello all,
>
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
>
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
>
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
>
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
>
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
>
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
>
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
>
> --
> Pieter
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[Pieter Wuille]

On Sat, Jun 20, 2015 at 7:26 PM, David Vorick 
wrote:

> I see it as unreasonable to expect all nodes to upgrade during a hardfork.
> If you are intentionally waiting for that to happen, it's possible for an
> extreme minority of nodes to hold the rest of the network hostage by simply
> refusing to upgrade. However you want nodes to be able to protest until it
> is clear that they have lost the battle without being at risk of getting
> hardforked out of the network unexpectedly.
>

You can't observe the majority of nodes, only miners, and weighed by
hashrate. If you need a mechanism for protest, that should happen before
the hard fork change code is rolled out. I am assuming a completely
uncontroversial change, in order to not confuse this discussion with the
debate about what hard forks should be done.

So I am not talking about protest, just about deploying a change. And yes,
it is unreasonable to expect that every single node will upgrade. But there
is a difference between ignoring old unmaintained nodes that do not
influence anyone's behaviour, and ignoring the nodes that power miners
producing actual blocks. In addition, having no blocks on the old chain is
safer than producing a small number, as you want full nodes that have not
noticed the fork to fail rather than see a slow but otherwise functional
chain.

-- 
Pieter
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[Matt Whitlock]

On Saturday, 20 June 2015, at 8:11 pm, Pieter Wuille wrote:
> you want full nodes that have not noticed the fork to fail rather than see a 
> slow but otherwise functional chain.

Isn't that what the Alert mechanism is for? If these nodes continue running 
despite an alert telling them they're outdated, then it must be intentional.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Mailman incompatibility with DKIM ...

[Adam Weiss]

It changes the mechanics at least.  A quick glance at RFC(2)822 makes it
clear that this is a pretty weakly specified behavior and is somewhat of an
edge case.  However, rewriting the envelopes has become somewhat prevalent
since strict DMARC has been adopted and I suspect that most recent MUAs
will handle it well.  I know that at least with gmail it works as I would
expect.  (Makes sense considering that this is how Google Groups handles
the problem.)

In any event, I really think it's worth a shot since having the subject and
footer tags is valuable. If it turns out to be problematic, it's not the
end of the world and things could be easily switched to go the lkml route...

--adam


On Fri, Jun 19, 2015 at 4:44 PM, Jeff Garzik  wrote:

> On Fri, Jun 19, 2015 at 12:47 PM, Adam Weiss  wrote:
>
>> Hi Warren,
>>
>> If you set dmarc_moderation_action to "Munge from", the list will detect
>> when someone posts from a domain that publishes a request for strict
>> signature checking for all mails originating from it (in DNS) and rewrite
>> the envelope-from to the list's address.  Reply-to will be added and set to
>> the original sender.
>>
>
> That seems to change Reply behavior for those recipients?  It would seem
> to accidentally direct mail intended to DKIM-user + list to DKIM-user.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Hard fork via miner vote

[Roy Badami]

As I've observed before, Gavin originally advocated either a 99% or
100% buy in by miners for a hard fork to trigger.

https://gist.github.com/gavinandresen/2355445

I don't understand why people (Gavin included) now seem to favour a
much more modest supermajority except perhaps that they believe that
that level of consensus is unachievable.

FWIW I'm in favour of a block size increase.  I just wish that half as
much energy had gone into discussing whether we want a 100%
supermajority or a 99% supermajority or an 80% supermajority, as has
gone into discussing whether we want 1MB blocks or 8MB blocks or 20MB
blocks.  (So thank you, Pieter, for raising this.)

roy

On Sat, Jun 20, 2015 at 07:13:06PM +0200, Pieter Wuille wrote:
> Hello all,
> 
> I've seen ideas around hard fork proposals that involve a block version
> vote (a la BIP34, BIP66, or my more recent versionbits BIP draft). I
> believe this is a bad idea, independent of what the hard fork itself is.
> 
> Ultimately, the purpose of a hard fork is asking the whole community to
> change their full nodes to new code. The purpose of the trigger mechanism
> is to establish when that has happened.
> 
> Using a 95% threshold, implies the fork can happen when at least 5% of
> miners have not upgraded, which implies some full nodes have not (as miners
> are nodes), and in addition, means the old chain can keep growing too,
> confusing old non-miner nodes as well.
> 
> Ideally, the fork should be scheduled when one is certain nodes will have
> upgraded, and the risk for a fork will be gone. If everyone has upgraded,
> no vote is necessary, and if nodes have not, it remains risky to fork them
> off.
> 
> I understand that, in order to keep humans in the loop, you want an
> observable trigger mechanism, and a hashrate vote is an easy way to do
> this. But at least, use a minimum timestamp you believe to be reasonable
> for upgrade, and a 100% threshold afterwards. Anything else guarantees that
> your forking change happens *knowingly* before the risk is gone.
> 
> You may argue that miners would be asked to - and have it in their best
> interest - to not actually make blocks that violate the changed rule before
> they are reasonably sure that everyone has upgraded. That is possible, but
> it does not gain you anything over just using a 100% threshold, as how
> would they be reasonably sure everyone has upgraded, while blocks creater
> by non-upgraded miners are still being created?
> 
> TL;DR: use a timestamp switchover for a hard fork, or add a block voting
> threshold as a means to keep humans in the loop, but if you do, use 100% as
> threshold.
> 
> -- 
> Pieter

> --

> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter,

Recently there was a brouhaha over Coinbase censoring the ability of
firearms businesses to accept bitcoins via Coinbase
https://www.reddit.com/r/Bitcoin/comments/3agbs7/coinbase_shuts_down_bit
coin_biz_for_firearms/

The question and relevance here to this is that for people who are
going for the alternate route (e.g., bailing on Coinbase / Bitpay /
similar web wallets, in favor of setting up with something like
Electrum and using Gear https://gear.mycelium.com/ as payment
processor or Straight
https://github.com/snitko/straight-server,
what would be the answer to "What does this mean for me?" for this topic
?

On 06/19/2015 03:39 AM, 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
> will be replaced if a conflicting transaction pays a higher fee.
> There are no requirements for the replacement transaction to pay
> addresses that were paid by the previous transaction.
> 
> 
> I'm a user. What does this mean for me? 
> ---
> 
> In the short term, very little. Wallet software aimed at average
> users has no ability to reliably detect conditions where an
> unconfirmed transaction may be double-spent by the sender. For
> example, Schildbach's Bitcoin Wallet for Android doesn't even
> detect double-spends of unconfirmed transactions when connected to
> a RBF or Bitcoin XT nodes that propagate them. The least
> sophisticated double-spend attack possibly - simply broadcasting
> two conflicting transactions at the same time - has about 50%
> probability of success against these wallets.
> 
> Additionally, SPV wallets based on bitcoinj can't even detect
> invalid transactions reliably, instead trusting the full node(s) it
> is connected too over the unauthenticated, unencrypted, P2P
> protocol to do validation for them. For instance due to a unfixed
> bug¹ Bitcoin XT nodes will relay double-spends that spend the
> output of the conflicting transaction. I've personally tested this
> with Schildbach's Bitcoin Wallet for Android, which shows such
> invalid transactions as standard, unconfirmed, transactions.
> 
> Users should continue to assume that unconfirmed transactions could
> be trivially reversed by the sender until the first confirmation.
> In general, only the sender can reverse a transaction, so if you do
> trust the sender feel free to assume an unconfirmed transaction
> will eventually confirm. However, if you do not trust the sender
> and/or have no other recourse if they double-spend you, wait until
> at least the first confirmation before assuming the transaction
> will go through.
> 
> In the long term, miner support of full RBF has a number of
> advantages to users, allowing you to more efficiently make
> transactions, paying lower fees. However you'll need a wallet
> supporting these features; none exist yet.
> 
> 
> I'm a business. What does this mean for me? 
> ---
> 
> If you use your own node to verify transactions, you probably are
> in a similar situation as average users, so again, this means very
> little to you.
> 
> If you use a payment processor/transaction API such as BitPay,
> Coinbase, BlockCypher, etc. you may or may not be accepting
> unconfirmed transactions, and they may or may not be "guaranteed"
> by your payment processor even if double-spent. If like most
> merchants you're using the API such that confirmations are required
> prior to accepting orders (e.g. taking a meaningful loss such as
> shipping a product if the tx is reversed) nothing changes for you.
> If not I recommend you contact your payment processor.
> 
> 
> I'm a miner. Why should I support replace-by-fee? 
> -
> 
> Whether full or first-seen-safe⁵ RBF support (along with 
> child-pays-for-parent) is an important step towards a fully
> functioning transaction fee market that doesn't lead to users'
> transactions getting mysteriously "stuck", particularly during
> network flooding events/attacks. A better functioning fee market
> will help reduce pressure to increase the blocksize, particularly
> from the users creating the most valuable transactions.
> 
> Full RBF also helps make use of the limited blockchain space more 
> efficiently, with up to 90%+ transaction size savings possible in
> some transaction patterns. (e.g. long payment chains⁶) More users
> in less blockchain space will lead to higher overall fees per
> block.
> 
> Finally as we'll discuss below full RBF prevents a number of
> serious threats to the existing level playing field that miners
> operate in.
> 
> 
> Why can't we make accepting unconfirmed txs from untrusted people
> safe? 
> --
- -
>
>  For a decentralized wallet, the situation is 

Re: [Bitcoin-development] Hard fork via miner vote

[Roy Badami]

> I just wish that half as much energy had gone into discussing
> whether we want a 100% supermajority or a 99% supermajority or an
> 80% supermajority, as has gone into discussing whether we want 1MB
> blocks or 8MB blocks or 20MB blocks.

And I understand that Gavin is now proposing that a 75% supermajority
should be enough.  This constantly reducing threshold worries me
greatly.

There is a risk that we get a situation where a stable amount of
hashing power somewhat over 75% (say 80%) accepts the fork - and
therefore triggers it - but both a significant minority (say 20%) of
hashrate rejects it *and* the economic majority rejects it.

I'm not saying this is a likely outcome - indeed I hope it's not - but
it is a _possible_ outcome.  Ok, the chain that the economic marjority
is using will have a bit of a temporary crisis due to 50 minute block
times, but it will recover in a few weeks as difficulty adjusts.  And,
in the worst case, you end up with two competing semi-stable
ecosystems both claiming to be 'the real Bitcoin'.

My fear is that in that situation it could take an extended period -
perhaps many months - for one fork to clearly win and the other fork
to lose support (or at least lose sufficient support to be relegated
to altcoin status).  I think such an extended period of uncertainty
would be the ultimate worst case scenario for Bitcoin.  It _probably_
wouldn't be fatal to Bitcoin, but it would certainly be far worse for
Bitcoin than getting the blocksize wrong even by an order of magnitude
(in either direction).  Therefore if we can design the hardfork
mechanism to make such an outcome impossible, I believe we really need
to.

roy

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Jorge Timón]

This is an attempt to unify views on why and how hardforks can be
deployed. I would like to turn this into an informational BIP later
after gathering some feedback.

Please, do not discuss block size issues here: there's plenty of
threads to do so. The scope of this one is only hardforks and
softforks in a more abstract way. Sometimes block size changes are
used as examples because no other example came to mind
(non-blocksize-related examples for the same cases [or others] are
a user should be just ignored. But what if the welcomed), and
if we go into too much detail they stop being useful as examples. So
please, try to avoid going into too much detail about the concrete
examples when possible.

https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org

Please, feel free to make suggestions or bike-shed some of the terms.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

[Tier Nolan]

The off by 1 bug could be fixed by a soft fork.  Since the point is to show
how a non-controversial hard fork works, it doesn't matter much.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Jorge Timón]

On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  wrote:
> 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…

I disagree with this premise. Please, don't take this as an argument
from authority fallacy, but I will cite Satoshi to express what I
think the assumptions while using the system should be:

"As long as a majority of CPU power is controlled by nodes that are
not cooperating to attack the network, they'll generate the longest
chain and outpace attackers."

I can't say for sure what was meant by "attacking the network" in this
context but I personally mean trying to rewrite valid and
proof-of-work-timestamped history.
Unconfirmed transactions are simply not part of history yet. Ordering
unconfirmed transactions in a consensus compatible way without a
universal clock is impossible, that's why we're using proof of work in
the first place.

Alternative policies are NOT attacks on the network.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Jorge Timón]

On Fri, Jun 19, 2015 at 6:42 PM, 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 
> of intent to pay…

Non-repudiation can be built on top of the payment protocol layer.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[justusranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2015-06-20 18:20, Jorge Timón wrote:
> On Fri, Jun 19, 2015 at 6:42 PM, 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 of intent to pay…
> 
> Non-repudiation can be built on top of the payment protocol layer.


Non-repudiation is an intrinsic property of the ECDSA signatures which 
Bitcoin uses - it's not a feature that needs to be built.

There's no way to accidentally sign a transaction and accidentally 
announce it publicly. There is no form of third-party error that can 
result in a payee receiving an erroneous contract.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVhfkXAAoJECpf2nDq2eYjTwIP/ApsURTKJgAsSYb4/lvoujAE
EhOUBfmb+WkrEceASWGgmXFfQBQW7c99sT46cA1HdCPLZMtYhZYPubtYRouSupfF
vOfeKLsZsUXCadeLuzxP7av3PJhmvB1CO1Rv8CLBQptKUFkzyM3CypBviNTy33X6
KL2zyAMERpCVOejg7MSP3IUXIjgG1ayEm+mzwqi4j2Ms0h+oT6I/krAKV0J9SwJC
PtLq/JRRriVtb2FE+biEqYRYfeOcZDYNbr+/y0HPtqqMxg6azNwx1z2aG5A+ziCd
EvVqVJXU3TAINQdIvVS4ACF1J+ttMJ99r8VW0yN7o3fEckuRr3pyymx4I+XExSX5
ujflqadRGUS8ZenUPTPUbLfhARnmBwLM94L+xiQvIwiinxxtOKn3WW1oDv9FNp0l
99fkv9mbV5RnYlkMfWMn2AcwcBv7TSgpFGsZY4wBn/mgFh1PotGc2tA5kU79cz8R
+F/k49+GwfgTPML7UhIGtjQjPreeqDyHNtv9XHtyp8LF5vO1na4oHSO6SeU4rIXH
4oIjw+Q6X/2L/fp8QNLB+onmKWobcl1Ec+0H+ZfQBujtew5BHFwcPwFmlC4tofiJ
7r8QjoPsRhJmaxm+MJOK/BIzhZErkMz26AQ/tfY4jtJCuLbEDdMLtC9hYVuiDHIb
HBxxif83dALjX1Sgid66
=o9dG
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
> 
> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  wrote:
>> 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…
> 
> I disagree with this premise. Please, don't take this as an argument
> from authority fallacy, but I will cite Satoshi to express what I
> think the assumptions while using the system should be:
> 
> "As long as a majority of CPU power is controlled by nodes that are
> not cooperating to attack the network, they'll generate the longest
> chain and outpace attackers."
> 
> I can't say for sure what was meant by "attacking the network" in this
> context but I personally mean trying to rewrite valid and
> proof-of-work-timestamped history.
> Unconfirmed transactions are simply not part of history yet. Ordering
> unconfirmed transactions in a consensus compatible way without a
> universal clock is impossible, that's why we're using proof of work in
> the first place.
> 
> Alternative policies are NOT attacks on the network.

Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are 
part of any sort of global consensus. In fact, they very much AREN’T. Which is 
exactly why it is extremely dangerous to accept unconfirmed transactions as 
final unless you clearly have assessed the risks and it makes sense for the 
particular business use case.

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

I should also add that I think many in this space believe they have assessed 
the risk as acceptable but haven’t really considered how to cap potential 
losses nor made contingency plans for when the inevitable attacks *do* come.

- Eric Lombrozo

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  wrote:
>>> 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…
>> 
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>> 
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>> 
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>> 
>> Alternative policies are NOT attacks on the network.
> 
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions 
> are part of any sort of global consensus. In fact, they very much AREN’T. 
> Which is exactly why it is extremely dangerous to accept unconfirmed 
> transactions as final unless you clearly have assessed the risks and it makes 
> sense for the particular business use case.
> 
> - Eric Lombrozo



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo  wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón  wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo  wrote:
>>> 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…
>> 
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>> 
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>> 
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>> 
>> Alternative policies are NOT attacks on the network.
> 
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions 
> are part of any sort of global consensus. In fact, they very much AREN’T. 
> Which is exactly why it is extremely dangerous to accept unconfirmed 
> transactions as final unless you clearly have assessed the risks and it makes 
> sense for the particular business use case.
> 
> - Eric Lombrozo

I think the misunderstanding was in perhaps my earlier statement seemed like I 
was suggesting that it’s the protocol’s responsibility to protect merchants 
from double-spends. On the contrary - I think we agree - the protocol CANNOT 
make any guarantees to ANYONE until we do converge on a history. The “design” I 
speak of here is more on the merchant side.

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

> 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 
> > 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 of intent to pay…
> >
> > Non-repudiation can be built on top of the payment protocol layer.
> 
> 
> Non-repudiation is an intrinsic property of the ECDSA signatures which
> Bitcoin uses - it's not a feature that needs to be built.
> 
> There's no way to accidentally sign a transaction and accidentally
> announce it publicly. There is no form of third-party error that can
> result in a payee receiving an erroneous contract.
> 
> 

Justus,

We don’t even have a concept of identity in the Bitcoin protocol, let alone 
non-repudiation. What good is non-repudiation if there’s no way to even 
associate a signature with a legal entity?

Sure, we could use the ECDSA signatures in transactions as part of a 
non-repudiation scheme - but the recipient would have to also have a means to 
establish the identity of the sender and associate it with the the transaction.


Furthermore, in light of the fact that there *are* fully legitimate use cases 
for sending conflicting transactions…and the fact that determination of intent 
isn’t always entirely clear…we should refrain from attaching any further 
significance transaction signatures other than that “the sender was willing to 
have it included in the blockchain if a miner were to have seen it and accepted 
it…but perhaps the sender would have changed their mind before it actually did 
get accepted.”

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[justusranvier]

-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 
>> > 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 of intent to pay…
>> >
>> > Non-repudiation can be built on top of the payment protocol layer.
>> 
>> 
>> Non-repudiation is an intrinsic property of the ECDSA signatures which
>> Bitcoin uses - it's not a feature that needs to be built.
>> 
>> There's no way to accidentally sign a transaction and accidentally
>> announce it publicly. There is no form of third-party error that can
>> result in a payee receiving an erroneous contract.
>> 
>> 
> 
> Justus,
> 
> We don’t even have a concept of identity in the Bitcoin protocol, let
> alone non-repudiation. What good is non-repudiation if there’s no way
> to even associate a signature with a legal entity?
> 
> Sure, we could use the ECDSA signatures in transactions as part of a
> non-repudiation scheme - but the recipient would have to also have a
> means to establish the identity of the sender and associate it with
> the the transaction.
> 
> 
> Furthermore, in light of the fact that there *are* fully legitimate
> use cases for sending conflicting transactions…and the fact that
> determination of intent isn’t always entirely clear…we should refrain
> from attaching any further significance transaction signatures other
> than that “the sender was willing to have it included in the
> blockchain if a miner were to have seen it and accepted it…but perhaps
> the sender would have changed their mind before it actually did get
> accepted.”

Bitcoin has no concept of identity, but in any type of commercial 
transaction the parties involved must know some minimal amount of 
identity information in order to transact at all.

Except for some identifiable special cases, I think a payee is perfectly 
justified in treating a double spend of a payment sent to them as part 
of a commercial transaction as a fraud attempt and employing whatever 
non-Bitcoin recourse mechanisms, if any, they have access to.

- From the perspective of the network, the obviously correct action for 
any node or miner is to relay the first version of any transaction they 
see. The primary purpose of mining is to resolve this 
otherwise-unresolvable problem of determining which transaction among a 
set of conflicting transactions happened first.

If a node or miner wants to deviate from the obviously correct 
behaviour, and if they want to avoid harming the value of the network, 
they should be particularly careful to make sure their deviation from 
"first seen" doesn't introduce harmful unintended side effects, like 
making fraud easier.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJVhgTgAAoJECpf2nDq2eYjkksQAJyRVhT2vNQUqlOfH9Z/9EeT
LkUm8eg3f1i3xhJVxtLGVJkRmMYmuNtH0lIsH/B3iED732oZSzhwM1F5ky948Mw7
FFG65iUTrXVup9eKZuD7T3/FaQHfC5YME36F4UvEtSUcRDUKmongRGuuw7sNv617
APl3MDwZ8tVWaDb7yZ251is6Fx1l3b6tR4tHUzyIWPyIOuXOsyUaoS1cYJ00YcI5
WIzIXIlRDNpvpIXv4NFtr0BH6BmTCCZOJH3X9Hmtxqrg/dlnfnmc1pZgAyqRXj1d
5of7dYwb+bhHpU9TvcDYprN55Kmida2gTZewfr33rTXcVyjhs5N3bmIRIRrPltMA
fFqlKJ7Fo4ldyJ4OEK6upuFHwmQRNL7qr/ODmYg83rJj3BdTzXsJ1l3BRAUBS+cm
gc8Q3urxmVyspht+U64GO+ieLA9xb9izFMa+GL8nag0VuHc5J7XDjfzXBT8VK5be
646AZ0tFULNLOBWEJuBRbCRUs90YK2ePpGnAwiZ7HuwHMAC333FYiBuRxgwgn+xv
hHMlQWTtrl0zJrxD+pcb5axC7zQdVHVeyNJDi4RF1Wau2NX/itHcUqRr75N8/Si+
GPF8JSnvLlplEsEMBAtbKvg4dn1AOEuJpXtDYrWrzZDs+/wwz5PfQ2oCZ3YRHNx2
po6di9uOSlLq0BJJfSrM
=HbNG
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

> 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 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 of intent to pay…
> >> >
> >> > Non-repudiation can be built on top of the payment protocol layer.
> >>
> >>
> >> Non-repudiation is an intrinsic property of the ECDSA signatures which
> >> Bitcoin uses - it's not a feature that needs to be built.
> >>
> >> There's no way to accidentally sign a transaction and accidentally
> >> announce it publicly. There is no form of third-party error that can
> >> result in a payee receiving an erroneous contract.
> >>
> >>
> >
> > Justus,
> >
> > We don’t even have a concept of identity in the Bitcoin protocol, let
> > alone non-repudiation. What good is non-repudiation if there’s no way
> > to even associate a signature with a legal entity?
> >
> > Sure, we could use the ECDSA signatures in transactions as part of a
> > non-repudiation scheme - but the recipient would have to also have a
> > means to establish the identity of the sender and associate it with
> > the the transaction.
> >
> >
> > Furthermore, in light of the fact that there *are* fully legitimate
> > use cases for sending conflicting transactions…and the fact that
> > determination of intent isn’t always entirely clear…we should refrain
> > from attaching any further significance transaction signatures other
> > than that “the sender was willing to have it included in the
> > blockchain if a miner were to have seen it and accepted it…but perhaps
> > the sender would have changed their mind before it actually did get
> > accepted.”
> 
> Bitcoin has no concept of identity, but in any type of commercial
> transaction the parties involved must know some minimal amount of
> identity information in order to transact at all.
> 
> Except for some identifiable special cases, I think a payee is perfectly
> justified in treating a double spend of a payment sent to them as part
> of a commercial transaction as a fraud attempt and employing whatever
> non-Bitcoin recourse mechanisms, if any, they have access to.
> 
> From the perspective of the network, the obviously correct action for
> any node or miner is to relay the first version of any transaction they
> see. The primary purpose of mining is to resolve this
> otherwise-unresolvable problem of determining which transaction among a
> set of conflicting transactions happened first.
> 
> If a node or miner wants to deviate from the obviously correct
> behaviour, and if they want to avoid harming the value of the network,
> they should be particularly careful to make sure their deviation from
> "first seen" doesn't introduce harmful unintended side effects, like
> making fraud easier.
> 

The contract between the buyer and seller is actually outside the Bitcoin 
network. Yes, a merchant that gets cheated could seek some other recourse in 
such an event…but the behavior you’re claiming as “obviously correct” is NOT 
obviously correct.  In fact, there are arguments against this “obviously 
correct” way even if we were to accept the premise that the signature implies a 
promise to pay (which I think many reasonable individuals would also dispute). 
For instance, by relaying conflicting transactions it makes it potentially 
easier for others to discover the double-spend attempt (of course, this 
requires wallets to not be lazy about this…perhaps such relays could be flagged 
or placed in a special message type).

- Eric Lombrozo





signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo]

One more thing I would like to add to this thread: I want to make it 
unequivocally clear that I believe what is making double-spends easier has 
relatively little to do with the protocol and almost everything to do with poor 
software and poor security policy on the merchant end. Perhaps it isn’t prudent 
to push out changes to the relay policy that make these exploits even easier 
right now - but we NEED to be applying some kind of pressure on the merchant 
end to upgrade their stuff to be more resilient so that we have more room for 
changes on things like relay policy without significant disruption to the 
network.

- Eric Lombrozo


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Dario Sneidermanis]

se, lo re putearon a Peter Todd en reddit por esto
On Jun 19, 2015 7:42 AM, "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 will be replaced if a
> conflicting transaction pays a higher fee. There are no requirements for
> the replacement transaction to pay addresses that were paid by the
> previous transaction.
>
>
> I'm a user. What does this mean for me?
> ---
>
> In the short term, very little. Wallet software aimed at average users
> has no ability to reliably detect conditions where an unconfirmed
> transaction may be double-spent by the sender. For example, Schildbach's
> Bitcoin Wallet for Android doesn't even detect double-spends of
> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
> that propagate them. The least sophisticated double-spend attack
> possibly - simply broadcasting two conflicting transactions at the same
> time - has about 50% probability of success against these wallets.
>
> Additionally, SPV wallets based on bitcoinj can't even detect invalid
> transactions reliably, instead trusting the full node(s) it is connected
> too over the unauthenticated, unencrypted, P2P protocol to do validation
> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
> double-spends that spend the output of the conflicting transaction. I've
> personally tested this with Schildbach's Bitcoin Wallet for Android,
> which shows such invalid transactions as standard, unconfirmed,
> transactions.
>
> Users should continue to assume that unconfirmed transactions could be
> trivially reversed by the sender until the first confirmation. In
> general, only the sender can reverse a transaction, so if you do trust
> the sender feel free to assume an unconfirmed transaction will
> eventually confirm. However, if you do not trust the sender and/or have
> no other recourse if they double-spend you, wait until at least the
> first confirmation before assuming the transaction will go through.
>
> In the long term, miner support of full RBF has a number of advantages
> to users, allowing you to more efficiently make transactions, paying
> lower fees. However you'll need a wallet supporting these features; none
> exist yet.
>
>
> I'm a business. What does this mean for me?
> ---
>
> If you use your own node to verify transactions, you probably are in a
> similar situation as average users, so again, this means very little to
> you.
>
> If you use a payment processor/transaction API such as BitPay, Coinbase,
> BlockCypher, etc. you may or may not be accepting unconfirmed
> transactions, and they may or may not be "guaranteed" by your payment
> processor even if double-spent. If like most merchants you're using the
> API such that confirmations are required prior to accepting orders (e.g.
> taking a meaningful loss such as shipping a product if the tx is
> reversed) nothing changes for you. If not I recommend you contact your
> payment processor.
>
>
> I'm a miner. Why should I support replace-by-fee?
> -
>
> Whether full or first-seen-safe⁵ RBF support (along with
> child-pays-for-parent) is an important step towards a fully functioning
> transaction fee market that doesn't lead to users' transactions getting
> mysteriously "stuck", particularly during network flooding
> events/attacks. A better functioning fee market will help reduce
> pressure to increase the blocksize, particularly from the users creating
> the most valuable transactions.
>
> Full RBF also helps make use of the limited blockchain space more
> efficiently, with up to 90%+ transaction size savings possible in some
> transaction patterns. (e.g. long payment chains⁶) More users in less
> blockchain space will lead to higher overall fees per block.
>
> Finally as we'll discuss below full RBF prevents a number of serious
> threats to the existing level playing field that miners operate in.
>
>
> Why can't we make accepting unconfirmed txs from untrusted people safe?
> ---
>
> For a decentralized wallet, the situation is pretty bleak. These wallets
> only have a handful of connections to the network, with no way of
> knowing if those connections give an accurate view of what transactions
> miners actually know about.
>
> The only serious attempt to fix this problem for decentralized wallets
> that has been actually deployed is Andresen/Harding's double-spend
> relaying, implemented in Bitcoin XT. It relays up to one double-spend
> transaction per double-spent txout, with the intended effect to warn
> recipients. In practice however this functionality makes it easier to
> double-spend rather than harder, by giving an efficient and easy way to
> get double-spends to 

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Dario Sneidermanis]

Sorry about that, ignore me
On Jun 20, 2015 11:11 PM, "Dario Sneidermanis"  wrote:

> se, lo re putearon a Peter Todd en reddit por esto
> On Jun 19, 2015 7:42 AM, "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 will be replaced if a
>> conflicting transaction pays a higher fee. There are no requirements for
>> the replacement transaction to pay addresses that were paid by the
>> previous transaction.
>>
>>
>> I'm a user. What does this mean for me?
>> ---
>>
>> In the short term, very little. Wallet software aimed at average users
>> has no ability to reliably detect conditions where an unconfirmed
>> transaction may be double-spent by the sender. For example, Schildbach's
>> Bitcoin Wallet for Android doesn't even detect double-spends of
>> unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
>> that propagate them. The least sophisticated double-spend attack
>> possibly - simply broadcasting two conflicting transactions at the same
>> time - has about 50% probability of success against these wallets.
>>
>> Additionally, SPV wallets based on bitcoinj can't even detect invalid
>> transactions reliably, instead trusting the full node(s) it is connected
>> too over the unauthenticated, unencrypted, P2P protocol to do validation
>> for them. For instance due to a unfixed bug¹ Bitcoin XT nodes will relay
>> double-spends that spend the output of the conflicting transaction. I've
>> personally tested this with Schildbach's Bitcoin Wallet for Android,
>> which shows such invalid transactions as standard, unconfirmed,
>> transactions.
>>
>> Users should continue to assume that unconfirmed transactions could be
>> trivially reversed by the sender until the first confirmation. In
>> general, only the sender can reverse a transaction, so if you do trust
>> the sender feel free to assume an unconfirmed transaction will
>> eventually confirm. However, if you do not trust the sender and/or have
>> no other recourse if they double-spend you, wait until at least the
>> first confirmation before assuming the transaction will go through.
>>
>> In the long term, miner support of full RBF has a number of advantages
>> to users, allowing you to more efficiently make transactions, paying
>> lower fees. However you'll need a wallet supporting these features; none
>> exist yet.
>>
>>
>> I'm a business. What does this mean for me?
>> ---
>>
>> If you use your own node to verify transactions, you probably are in a
>> similar situation as average users, so again, this means very little to
>> you.
>>
>> If you use a payment processor/transaction API such as BitPay, Coinbase,
>> BlockCypher, etc. you may or may not be accepting unconfirmed
>> transactions, and they may or may not be "guaranteed" by your payment
>> processor even if double-spent. If like most merchants you're using the
>> API such that confirmations are required prior to accepting orders (e.g.
>> taking a meaningful loss such as shipping a product if the tx is
>> reversed) nothing changes for you. If not I recommend you contact your
>> payment processor.
>>
>>
>> I'm a miner. Why should I support replace-by-fee?
>> -
>>
>> Whether full or first-seen-safe⁵ RBF support (along with
>> child-pays-for-parent) is an important step towards a fully functioning
>> transaction fee market that doesn't lead to users' transactions getting
>> mysteriously "stuck", particularly during network flooding
>> events/attacks. A better functioning fee market will help reduce
>> pressure to increase the blocksize, particularly from the users creating
>> the most valuable transactions.
>>
>> Full RBF also helps make use of the limited blockchain space more
>> efficiently, with up to 90%+ transaction size savings possible in some
>> transaction patterns. (e.g. long payment chains⁶) More users in less
>> blockchain space will lead to higher overall fees per block.
>>
>> Finally as we'll discuss below full RBF prevents a number of serious
>> threats to the existing level playing field that miners operate in.
>>
>>
>> Why can't we make accepting unconfirmed txs from untrusted people safe?
>> ---
>>
>> For a decentralized wallet, the situation is pretty bleak. These wallets
>> only have a handful of connections to the network, with no way of
>> knowing if those connections give an accurate view of what transactions
>> miners actually know about.
>>
>> The only serious attempt to fix this problem for decentralized wallets
>> that has been actually deployed is Andresen/Harding's double-spend
>> relaying, implemented in Bitcoin XT. It relays up to one double-spend
>> transaction per double-spent txout, with the intended eff

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Tom Harding]

On 6/20/2015 5:54 PM, Eric Lombrozo wrote:
> Perhaps it isn’t prudent to push out changes to the relay policy that make 
> these exploits even easier right now - but we NEED to be applying some kind 
> of pressure on the merchant end to upgrade their stuff to be more resilient 
> so that we have more room for changes on things like relay policy without 
> significant disruption to the network.
>

There's no need to worry about causing more problems by relaying
double-spends.  After a year of watching, it's clear that already only
20% of hash power strictly obeys first-seen.

http://i.imgur.com/0bYXrjn.png

It may be surprising that
 - The period of ambiguity is very short - just 2 seconds
   (this makes sense, given the .5s median propagation time)
 - Fast double-spends between 2 and 15 seconds are less successful
 - The steady-state 80% respend success rate is reached after just 15
seconds

The >30s data point includes txes that were respent after a long time,
sometimes months.  Those longer-term respends are to be expected, as
people reclaim stuck txes.

Paying attention to double-spends is an opportunity for wallets and
merchants .  With 140 Bitcoin XT nodes online, you're probably already
receiving them.  Most wallets, including vanilla core, don't even alert
when a double-spend of a wallet transaction appears in a block - even
though there may still be time to withhold delivery of the goods/services.

If FSS RBF gains miner share, fewer successful zero-conf double-spends
will occur.  Only radical twisted logic finds that to be an undesirable
result.



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Jeff Garzik]

On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo  wrote:

>  but we NEED to be applying some kind of pressure on the merchant end to
> upgrade their stuff to be more resilient
>

Can you be specific?  What precise technical steps would you have BitPay
and Coinbase do?  We upgrade our stuff to... what exactly?

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development