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

[Eric Lombrozo]

> 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



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] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

[David Vorick]

I disagree that 11 is a reasonable value. That's less than 2 hours, which
probably wouldn't even last peak trading hours. You want the mempool to be
big enough that low-fee transactions introduced during peak hours are still
around when there's much less activity (it maximizes miner profit and
prevents people/wallets from needing to resubmit after activity has died
down).

I think you'd want something closer to 72. At 1mb or even 8mb blocks, the
memory requirements are pretty reasonable. 20mb blocks and you may have to
reconsider that limit.

On Tue, Jun 9, 2015 at 3:03 PM, Raystonn .  wrote:

>   You are right of course.  This will work.  I like this idea more than
> my own proposed fix, as it doesn’t make any big changes to the economics of
> the system in the way that burning would have.
>
>  *From:* Gavin Andresen 
> *Sent:* Tuesday, June 09, 2015 11:25 AM
> *To:* Raystonn . 
> *Cc:* Loi Luu  ; Bitcoin Dev
> 
> *Subject:* Re: [Bitcoin-development] New attack identified and potential
> solution described: Dropped-transaction spam attack against the block size
> limit
>
>   On Tue, Jun 9, 2015 at 1:52 PM, Raystonn .  wrote:
>
>>   That does sound good on the surface, but how do we enforce #1 and #2?
>> They seem to be unenforceable, as a miner can adjust the size of the memory
>> pool in his local source.
>>
>
> It doesn't have to be enforced. As long as a reasonable percentage of hash
> rate is following that policy an attacker that tries to flood the network
> will fail to prevent normal transaction traffic from going through and will
> just end up transferring some wealth to the miners.
>
> Although the existing default mining policy (which it seems about 70% of
> hashpower follows) of setting aside some space for high-priority
> transactions regardless of fee might also be enough to cause this attack to
> fail in practice.
>
> --
> --
> Gavin Andresen
>
>
>
> --
>
> ___
> 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

[Luke Dashjr]

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

--
___
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]

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 assumptions…and 
probably would not be able to gracefully handle very many risk scenarios.

- Eric Lombrozo


> On Jun 19, 2015, at 6:23 PM, Aaron Voisine  wrote:
> 
> > 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, for instance, credit card payments that can be charged back. As long as 
> it's reasonably good in practice, that's fine.
> 
> 
> Aaron Voisine
> co-founder and CEO
> breadwallet.com 
> On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach  > wrote:
> 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  > wrote:
> 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 bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
> 
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
> 
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
> 
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
> 
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
> 
> 
> --
> 
> ___
> 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



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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Tom Harding]

On 6/19/2015 6:43 AM, Mike Hearn wrote:
> No surprise, the position of Blockstream employees is that hard forks
> must never happen and that everyone's ordinary transactions should go
> via some new network that doesn't yet exist.

If my company were working on spiffy new ideas that required a hard fork
to implement, I'd be rather dismayed to see the blocksize hard fork
happen *before those ideas were ready*.

Because then I'd eventually have to convince people that those ideas
were worth a hard fork all on their own.  It would be much easier to
convince people to roll them in with the already necessary blocksize
hard fork, if that event could be delayed.

As far as I know, Blockstream representatives have never said that
waiting for other changes to be ready is a reason to delay the blocksize
hard fork.  So if this were the real reason, it would suggest they have
been hiding their true motives for making such a fuss about the
blocksize issue.

I've got no evidence at all to support thoughts like this... just the
paranoid mindset that seems to infect a person who gets involved in
bitcoin.  But the question is every bit as valid as Adam's query into
your motives.



--
___
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?

[Matt Smith]

> to avoid having an internal mapping from 9'-> 0' to find out what
> blockchain to query, this sounds like it should be trivial for any wallet.

Trivial to implement, a headache to *maintain*

But if a new platform is released on an existing blockchain, my wallet
doesn't need to know about the new magic number it claims in order to
handle it correctly.

Say I make a new token layer, BobCoin, which runs on bitcoin and say I
use an HD wallet and always generate new BobCoin token addresses as
m/##'/0'/808'/*'/*/*. If I import that wallet into older HD wallet
software that doesn't know anything about BobCoin, it will still:

- understand what blockchain to query for utxos on the addresses below
that path
- be able to generate valid BobCoin addresses without any updates

I think this is particularly valuable if you're developing against a
platform where updates can't be forced on clients.

To be clear: I am not suggesting this as a general-purpose successor to
BIP44.

–
Matt Smith | Gem
https://gem.co | GH: @thedoctor


On 6/19/15 5:57 PM, Andreas Petersson wrote:
>> m/##'/0'/99'/0'
>>
>> where 99 is the identifier for, say, counterparty
> 
> 
> What is stopping you from using m/44'/9'/a'/c/i as descibed here:
> http://doc.satoshilabs.com/slips/slip-0044.html
> 
> to avoid having an internal mapping from 9'-> 0' to find out what
> blockchain to query, this sounds like it should be trivial for any wallet.
> 
> 
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 



signature.asc
Description: OpenPGP digital signature
--
___
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?

[Matt @ Envrin Group]

Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which 
is what your proposed path structure would be, and it results in the 
address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w.

When the wallet notices a transaction in the blockchain that has 
1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an output, it's going to have to 
lookup the address within its database to get the values 6/4/7/99/0/196, 
as there's no way to retrieve them from just the address.  So 
technically, you might as well just use m/account'/change/index if using 
hardened child keys, or m/change/index if not, as recommended, because 
the wallet will still function the exact same way.

Matt



On 06/20/2015 06:31 AM, Matt Smith wrote:
> I'm not sure I understand your question about the need to store paths in
> the wallet database -- there's no way to infer the path of an address
> inside an HD wallet from the address alone (short of an exhaustive
> search), and HD wallets need to store either the paths, addresses, or
> both that have been previously derived/used to monitor the blockchain
> usefully, but those facts aren't new or specific to this path format.
>
> The motivation for this path structure over standard bip44 is that it
> separates the concept of network (or which blockchain I'm using) and
> coin_type (or what kind of thing I'm sending over that blockchain).
>
> This is useful, for example, if I want to import a wallet into my
> application and I know that an account was in use at
>
> m/##'/0'/99'/0'
>
> where 99 is the identifier for, say, counterparty - I only need to check
> the addresses derived below that path for balances against
> counterpartyd. It may be worth pointing out that I expect multisig HD
> wallet imports to require master keys and a list of account paths – not
> a list of addresses, as it's very possible that a new address could be
> derived between the time when the wallet data was exported and when it
> will be imported.
>
> This use case might be very specific to our model, but the reason I
> figured we should request a BIP # for this is that to start using it, we
> need to pick a number for the purpose field and don't want to do it
> arbitrarily (and risk having to change it later) or overload 44 (which
> would be misleading).
>
> Did I either  a) answer  or  b) misunderstand  your questions?
> --
> Matt Smith | Gem
> https://gem.co | GH: @thedoctor
>
>
>
> On 6/19/15 2:25 PM, Matt @ Envrin Group wrote:
>> Hi Matt,
>>
>> I think your best bet is probably just push it out privately via blog
>> post / Github, and see if it gains any traction with other developers.
>>
>> I'm a little uncertain as to the relevance though.  All those variables
>> (purpose, network, asset_type, account, change, index) need to be stored
>> internally within the wallet database, as there's no way to retrieve the
>> path used from just the address, correct?  In that case, what's the
>> meaning of that exact path structure when a) it can't be retrieved from
>> just the address, and b) the values will be stored internally within the
>> wallet when you lookup the address.
>>
>> Matt


--
___
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

[Aaron Voisine]

> 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, for instance, credit card payments that can be charged back. As
long as it's reasonably good in practice, that's fine.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach 
wrote:

> 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 
> wrote:
>
>> 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 bill for a sandwich might turn out fake later)
>> and the fraud frequency is also much lower.
>>
>> 0-conf concerns were never a problem in practice. except for 2-way atms
>> i have never heard of a problem that was caused by double spends.
>> while adding these measures is generally positive, requiring them means
>> excluding 99.9% of the potential users. so you might as well not do it.
>>
>> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
>> value. So it's a bad thing.
>>
>> for any online or automated system, waiting for a handful of
>> confirmations was always recommended practice.
>>
>> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
>> > Retail POS merchants probably should not be accepting vanilla Bitcoin
>> > payments, as Bitcoin alone does not (and cannot) guarantee the
>> > irreversibility of a transaction until it has been buried several
>> > blocks deep in the chain. Retail merchants should be requiring a
>> > co-signature from a mutually trusted co-signer that vows never to sign
>> > a double-spend.
>>
>>
>>
>> --
>>
>> ___
>> 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

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

[Mark Friedenbach]

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 
wrote:

> 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 bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
>
> --
>
> ___
> 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

[Andreas Petersson]

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 bill for a sandwich might turn out fake later)
and the fraud frequency is also much lower.

0-conf concerns were never a problem in practice. except for 2-way atms
i have never heard of a problem that was caused by double spends.
while adding these measures is generally positive, requiring them means
excluding 99.9% of the potential users. so you might as well not do it.

RBF as implemented by F2Pool just flat out lowers Bitcoins utility
value. So it's a bad thing.

for any online or automated system, waiting for a handful of
confirmations was always recommended practice.

Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> Retail POS merchants probably should not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several
> blocks deep in the chain. Retail merchants should be requiring a
> co-signature from a mutually trusted co-signer that vows never to sign
> a double-spend.  



0xAA4EDEEF.asc
Description: application/pgp-keys
--
___
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?

[Andreas Petersson]

>m/##'/0'/99'/0'
>
>where 99 is the identifier for, say, counterparty


What is stopping you from using m/44'/9'/a'/c/i as descibed here:
http://doc.satoshilabs.com/slips/slip-0044.html

to avoid having an internal mapping from 9'-> 0' to find out what
blockchain to query, this sounds like it should be trivial for any wallet.


--
___
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?

[Matt Smith]

I'm not sure I understand your question about the need to store paths in
the wallet database -- there's no way to infer the path of an address
inside an HD wallet from the address alone (short of an exhaustive
search), and HD wallets need to store either the paths, addresses, or
both that have been previously derived/used to monitor the blockchain
usefully, but those facts aren't new or specific to this path format.

The motivation for this path structure over standard bip44 is that it
separates the concept of network (or which blockchain I'm using) and
coin_type (or what kind of thing I'm sending over that blockchain).

This is useful, for example, if I want to import a wallet into my
application and I know that an account was in use at

m/##'/0'/99'/0'

where 99 is the identifier for, say, counterparty - I only need to check
the addresses derived below that path for balances against
counterpartyd. It may be worth pointing out that I expect multisig HD
wallet imports to require master keys and a list of account paths – not
a list of addresses, as it's very possible that a new address could be
derived between the time when the wallet data was exported and when it
will be imported.

This use case might be very specific to our model, but the reason I
figured we should request a BIP # for this is that to start using it, we
need to pick a number for the purpose field and don't want to do it
arbitrarily (and risk having to change it later) or overload 44 (which
would be misleading).

Did I either  a) answer  or  b) misunderstand  your questions?
--
Matt Smith | Gem
https://gem.co | GH: @thedoctor



On 6/19/15 2:25 PM, Matt @ Envrin Group wrote:
> 
> Hi Matt,
> 
> I think your best bet is probably just push it out privately via blog
> post / Github, and see if it gains any traction with other developers.
> 
> I'm a little uncertain as to the relevance though.  All those variables
> (purpose, network, asset_type, account, change, index) need to be stored
> internally within the wallet database, as there's no way to retrieve the
> path used from just the address, correct?  In that case, what's the
> meaning of that exact path structure when a) it can't be retrieved from
> just the address, and b) the values will be stored internally within the
> wallet when you lookup the address.
> 
> Matt



signature.asc
Description: OpenPGP digital signature
--
___
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?

[Matt @ Envrin Group]

Hi Matt,

I think your best bet is probably just push it out privately via blog 
post / Github, and see if it gains any traction with other developers.


I'm a little uncertain as to the relevance though.  All those variables 
(purpose, network, asset_type, account, change, index) need to be stored 
internally within the wallet database, as there's no way to retrieve the 
path used from just the address, correct?  In that case, what's the 
meaning of that exact path structure when a) it can't be retrieved from 
just the address, and b) the values will be stored internally within the 
wallet when you lookup the address.


Matt



On 06/20/2015 03:42 AM, Matt Smith wrote:

Hey guys,

The crew at Gem is considering a new HD wallet path structure for our
wallets, which are coin-agnostic, that separates the coin_type field
into two fields as such:

m / purpose' / network' / asset_type' / account' / change / index

where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
litecoin, etc) and the new asset_type refers to the kind of asset to be
held in accounts below that path (Open Assets, Omni, Counterparty).

The intent is to allow us to validate the address format, select the
appropriate daemon to scan for tokenized assets, and choose multiple
blockchain data sources (that may not know anything about token systems
running on the blockchain they expose) relevant to an HDNode in the
wallet using only information in the HDNode's path -- without having to
maintain an explicit mapping of coin_type -> network.

For example, we already have the issue of mapping network identifiers
because of the lack of standardization across cryptocurrency libraries
which ends up being ugly and obnoxious to maintain, i.e.

netcode_map = {
   testnet: testnet3,
   bitcoin_testnet: testnet3,
   testnet3: testnet3,
   XTN: testnet3, ...
}
netcode_i_want = netcode_map[netcode_returned_by_libwhatever]

We want to avoid maintaining a similar asset_type_to_blockchain mapping.
Additionally, it would be helpful for utxo selection to exclude utxos
tied to assets based on path.

BIP43 seems to suggest that we request a BIP number and publish an
informational BIP specifying the new purpose. If that's not appropriate,
then maybe we just need to publish the information in a blog post to
allow any wallet developers who want to to implement
import_from_gem_structure.

I was also wondering if anyone had previously suggested something
similar that I missed when cruising the mailing list archives on the
subject.

Thanks,
--
Matt Smith | Gem
https://gem.co | GH: @thedoctor


--


___
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

[Jeff Garzik]

Double spend detection is by definition best-effort.

The purpose of bitcoin is to provide security (confirmations) to otherwise
insecure, possibly double spent transactions.




On Fri, Jun 19, 2015 at 2:05 PM, Frank Flores  wrote:

> Has anyone from Mycelium weighed in on this? Is their doublespend attack
> detection broken with this kind of irresponsible behavior?
>
> On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock 
> wrote:
>
>> 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 not be accepting vanilla Bitcoin
>> payments, as Bitcoin alone does not (and cannot) guarantee the
>> irreversibility of a transaction until it has been buried several blocks
>> deep in the chain. Retail merchants should be requiring a co-signature from
>> a mutually trusted co-signer that vows never to sign a double-spend. The
>> reason we don't yet see such technology permeating the ecosystem is
>> because, to date, zero-conf transactions have been irreversible "enough,"
>> but this has only been a happy accident; it was never promised, and it
>> should not be relied upon.
>>
>>
>> --
>> ___
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> *MONEY IS OVER!*
> IF YOU WANT IT
> 
> =
> The causes of my servitude can be traced to the tyranny of money.
> -Serj Tankian
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
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

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

[Matt Smith]

Hey guys,

The crew at Gem is considering a new HD wallet path structure for our
wallets, which are coin-agnostic, that separates the coin_type field
into two fields as such:

m / purpose' / network' / asset_type' / account' / change / index

where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
litecoin, etc) and the new asset_type refers to the kind of asset to be
held in accounts below that path (Open Assets, Omni, Counterparty).

The intent is to allow us to validate the address format, select the
appropriate daemon to scan for tokenized assets, and choose multiple
blockchain data sources (that may not know anything about token systems
running on the blockchain they expose) relevant to an HDNode in the
wallet using only information in the HDNode's path -- without having to
maintain an explicit mapping of coin_type -> network.

For example, we already have the issue of mapping network identifiers
because of the lack of standardization across cryptocurrency libraries
which ends up being ugly and obnoxious to maintain, i.e.

netcode_map = {
  testnet: testnet3,
  bitcoin_testnet: testnet3,
  testnet3: testnet3,
  XTN: testnet3, ...
}
netcode_i_want = netcode_map[netcode_returned_by_libwhatever]

We want to avoid maintaining a similar asset_type_to_blockchain mapping.
Additionally, it would be helpful for utxo selection to exclude utxos
tied to assets based on path.

BIP43 seems to suggest that we request a BIP number and publish an
informational BIP specifying the new purpose. If that's not appropriate,
then maybe we just need to publish the information in a blog post to
allow any wallet developers who want to to implement
import_from_gem_structure.

I was also wondering if anyone had previously suggested something
similar that I missed when cruising the mailing list archives on the
subject.

Thanks,
–
Matt Smith | Gem
https://gem.co | GH: @thedoctor


0x63331857.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital 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

[Frank Flores]

Has anyone from Mycelium weighed in on this? Is their doublespend attack
detection broken with this kind of irresponsible behavior?

On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock 
wrote:

> 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 not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several blocks
> deep in the chain. Retail merchants should be requiring a co-signature from
> a mutually trusted co-signer that vows never to sign a double-spend. The
> reason we don't yet see such technology permeating the ecosystem is
> because, to date, zero-conf transactions have been irreversible "enough,"
> but this has only been a happy accident; it was never promised, and it
> should not be relied upon.
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
*MONEY IS OVER!*
IF YOU WANT IT

=
The causes of my servitude can be traced to the tyranny of money.
-Serj Tankian
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Jeff Garzik]

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] F2Pool has enabled full replace-by-fee

[Matt Whitlock]

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 not be accepting vanilla Bitcoin payments, 
as Bitcoin alone does not (and cannot) guarantee the irreversibility of a 
transaction until it has been buried several blocks deep in the chain. Retail 
merchants should be requiring a co-signature from a mutually trusted co-signer 
that vows never to sign a double-spend. The reason we don't yet see such 
technology permeating the ecosystem is because, to date, zero-conf transactions 
have been irreversible "enough," but this has only been a happy accident; it 
was never promised, and it should not be relied upon.

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

Re: [Bitcoin-development] Remove Us Please

[Jameson Lopp]

You're only strengthening Gigas' point about the mailing list by posting
derisive emails. Take your nonconstructive comments elsewhere.

- Jameson

On Fri, Jun 19, 2015 at 4:01 PM, Brian Hoffman 
wrote:

> damn he was just on the verge of solving the underlaying problem with
> Bitcoin and you interrupted his focus.
>
> On Jun 19, 2015, at 3:55 PM, John Bodeen  wrote:
>
> from their website, humorous bits highlighted
>
>
>> *October 14, 2014 *In latest Hiatus new, the company has taken on yet
>> another crazy project but this one is going to benefit the world in which
>> it entered not long ago.  The company had done a lot of research on crypto
>> currencies, built one for itself, for testing purposes (GigasCorpCoin) and
>> found the underlaying problem of Bitcoin and was poised to solve it.
>> Company execs decided it would be a good investment to launch its own coin
>> and back it itself.
>> The company is currently in motion and will hire an expert to do some of
>> the coding by October 14, 2015.  Company President refused to be
>> interviewed due to too much work that needs done for this secret and
>> upcoming project.
>
>
> On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp 
> wrote:
>
>> You are free to remove yourself; the URL is at the bottom of every email:
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <
>> corpor...@gigasgaming.com> wrote:
>>
>>> This is no longer a mailing list, this is a chatroom.
>>> Please remove this email from your list, you are now interfering with
>>> official company business.
>>>
>>> Thanks
>>>
>>>
>>> --
>>> ___
>>> 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 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

[Jeffrey Paul]

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?

Best,
-jp

-- 
Jeffrey Paul   +1 (312) 361-0355
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2

> On 19.06.2015, at 15:52, 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 how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
> 
>> On Fri, Jun 19, 2015 at 9:44 PM, 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 supporting full RBF over FSS RBF would likely be
>>> negligible. Did they consider using FSS RBF instead?
>> 
>> Specifically the following is what I told them:
>> 
>>> We are
>>> interested in the replace-by-fee patch, but I am not following the
>>> development closely, more background info is needed, like what the
>>> difference between standard and zeroconf versions? Thanks.
>> 
>> Great!
>> 
>> Basically both let you replace one transaction with another that pays a
>> higher fee. First-seen-safe replace-by-fee adds the additional criteria
>> that all outputs of the old transaction still need to be paid by the new
>> transaction, with >= as many Bitcoins. Basically, it makes sure that if
>> someone was paid by tx1, then tx2 will still pay them.
>> 
>> I've written about how wallets can use RBF and FSS-RBF to more
>> efficiently use the blockchain on the bitcoin-development mailing list:
>> 
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
>> 
>> Basically, for the purpose of increasing fees, RBF is something like %50
>> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>> 
>> In addition, for ease of implementation, my new FSS-RBF has a number of
>> other restrictions. For instance, you can't replace multiple
>> transactions with one, you can't replace a transaction whose outputs
>> have already been spent, you can't replace a transaction with one that
>> spends additional unconfirmed inputs, etc. These restrictions aren't
>> "set in stone", but they do make the code simpler and less likely to
>> have bugs.
>> 
>> In comparison my previous standard RBF patch can replace multiple
>> transactions with one, can replace long chains of transactions, etc.
>> It's willing to do more computation before deciding if a transaction
>> should be replaced, with more complex logic; it probably has a higher
>> chance of having a bug or DoS attack.
>> 
>> You've probably seen the huge controversy around zeroconf with regard to
>> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
>> it also doesn't make it any more dangerous, so politically with regard
>> to zeroconf it makes no difference. You *can* still use it doublespend
>> by taking advantage of how different transactions are accepted
>> differently, but that's true of *every* change we've ever made to
>> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
>> zeroconf in the same way.
>> 
>> 
>> 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
>> supporting miners to figure out what transactions are being mined, are
>> services having any hope of avoiding getting ripped off. For the average
>> user their wallets do a terrible job of showing whether or not an
>> unconfirmed transaction will go through. For example, Schildbach's
>> Bitcoin wallet for Android has no code at all to detect double-spends
>> until they get mined, and I've been able to trick it into showing
>> completely invalid transactions. In fact, currently Bitcoin XT will
>> relay invalid transactions that are doublepsends, and Schildbach's
>> wallet displays them as valid, unconfirmed, payments. It's really no
>> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
>> unconfirmed transactions without some kind of protection that doesn't
>> rely on first-seen-safe mempool behavior. For instance, many ATM's these
>> days know who their customers are due to AML requirements, so while you
>> can deposit Bitcoins and get your funds instantly, the protection for
>> the ATM operator is that they can go to the police if you rip them off;
>> I've spoken to ATM operators who didn't do this who've lost hundreds or
>> even thousa

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

[Adam Weiss]

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.

I think that this is probably a better way to workaround the issue (rather
than playing with getting the list to not break the signature) until these
things mature further.

Thoughts?

--adam




On Fri, Jun 19, 2015 at 6:38 AM, Warren Togami Jr. 
wrote:

> On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn  wrote:
>
>> The new list currently has footers removed during testing.  I am not
>>> pleased with the need to remove the subject tag and footer to be more
>>> compatible with DKIM users.
>>>
>>
>> Lists can do what are effectively MITM attacks on people's messages in
>> any way they like, if they resign for the messages themselves. That seems
>> fair to me!  :)
>>
>
> Mailman isn't resigning it.  Should it be?  Does other mailing list
> software?
>
>
>>
>>
>>>  I'm guessing DKIM enforcement is not very common because of issues like
>>> this?
>>>
>>
>> DKIM is used by most mail on the internet. DMARC rules that publish in
>> DNS statements like "All mail from bitpay.com is signed correctly so
>> trash any that isn't" are used on some of the worlds most heavily phished
>> domains like google.com, PayPal, eBay, and indeed BitPay.
>>
>> These rules are understood and enforced by all major webmail providers
>> including Gmail. It's actually only rusty geek infrastructure that has
>> problems with this, I've never heard of DKIM/DMARC users having issues
>> outside of dealing with mailman. The vast majority of email users who never
>> post to technical mailing lists benefit from it significantly.
>>
>> Really everyone should use them. Adding cryptographic integrity to email
>> is hardly a crazy idea :)
>>
>
> I understand the reason to protect the "heavily phished" domains.  I heard
> that LKML does not modify the subject or add a footer, perhaps because it
> would make it incompatible with DKIM of the several big corporate domains
> who participate.
>
> I suppose it is somewhat acceptable for us to remove subject tags and
> footers if we have no choice...
>
> Warren
>
>
> --
>
> ___
> 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] Remove Us Please

[Brian Hoffman]

damn he was just on the verge of solving the underlaying problem with Bitcoin 
and you interrupted his focus.

> On Jun 19, 2015, at 3:55 PM, John Bodeen  wrote:
> 
> from their website, humorous bits highlighted
> 
> October 14, 2014 
> In latest Hiatus new, the company has taken on yet another crazy project but 
> this one is going to benefit the world in which it entered not long ago.  The 
> company had done a lot of research on crypto currencies, built one for 
> itself, for testing purposes (GigasCorpCoin) and found the underlaying 
> problem of Bitcoin and was poised to solve it.  Company execs decided it 
> would be a good investment to launch its own coin and back it itself.
> The company is currently in motion and will hire an expert to do some of the 
> coding by October 14, 2015.  Company President refused to be interviewed due 
> to too much work that needs done for this secret and upcoming project.
> 
> On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp  > wrote:
> You are free to remove yourself; the URL is at the bottom of every email: 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
> 
> 
> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. 
> mailto:corpor...@gigasgaming.com>> wrote:
> This is no longer a mailing list, this is a chatroom.
> Please remove this email from your list, you are now interfering with
> official company business.
> 
> Thanks
> 
> --
> ___
> 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 mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Remove Us Please

[John Bodeen]

from their website, humorous bits highlighted


> *October 14, 2014 *In latest Hiatus new, the company has taken on yet
> another crazy project but this one is going to benefit the world in which
> it entered not long ago.  The company had done a lot of research on crypto
> currencies, built one for itself, for testing purposes (GigasCorpCoin) and
> found the underlaying problem of Bitcoin and was poised to solve it.
> Company execs decided it would be a good investment to launch its own coin
> and back it itself.
> The company is currently in motion and will hire an expert to do some of
> the coding by October 14, 2015.  Company President refused to be
> interviewed due to too much work that needs done for this secret and
> upcoming project.


On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp 
wrote:

> You are free to remove yourself; the URL is at the bottom of every email:
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <
> corpor...@gigasgaming.com> wrote:
>
>> This is no longer a mailing list, this is a chatroom.
>> Please remove this email from your list, you are now interfering with
>> official company business.
>>
>> Thanks
>>
>>
>> --
>> ___
>> 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

Re: [Bitcoin-development] Remove Us Please

[Jameson Lopp]

You are free to remove yourself; the URL is at the bottom of every email:
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <
corpor...@gigasgaming.com> wrote:

> This is no longer a mailing list, this is a chatroom.
> Please remove this email from your list, you are now interfering with
> official company business.
>
> Thanks
>
>
> --
> ___
> 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] Remove Us Please

[Gigas Gaming Inc.]

This is no longer a mailing list, this is a chatroom.
Please remove this email from your list, you are now interfering with 
official company business.

Thanks

--
___
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: 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 see conflicting 
transactions on the network as part of a micropayment channel, and not 
know it was observing the resolution of a channel rather than a likely 
retail double spend.

If both transactions have been broadcast, then one of the conflicting 
members of the set will have nSequence adjustments.

Maybe a clever griefer could try to make their retail double spend look 
like a micropayment channel, but it seems like they'd be missing the 
other identifiable markers of that protocol.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFhqAAoJECpf2nDq2eYjWtgP/2ir11TUfxoIIzK9t0groKY3
yMR32HP3caDLKdc5ML41jf0l0cp7a54sFPuRE+Am8rkg9ogcf6fho/hCwLnhhNb4
YYBqJ2pzqCU1uN8jwPYSwSw3AO+F+hPE8gcm7lKD297a1k9xpYayAFjChJowoyNT
Wuq9YDkakQeSjV1aCiRHuXNxqnnbymf9xHEiB0buVnSgnyXrgZNCnefAo8DeXYqi
FTSceakNwdkklddK5ObNNK9ZoLpjHhX6hZwRiXsOoG+WUzXhLQ+BsyIFzsCKxQk1
cXjTvLn+Ub9FasRCK5KXMBkkPa1U5JLs1nTn6eTbPyroTs10WLkXWjIpZHrkf7ZW
9RsxoKIRaJur8gbYd6BMvV5rgkfGdb6j24pVNxFF2t89SLo44H0NvqE6koNzgubG
4DyXZ+UlzxzwRVBNDeF4pdlKZGsz2ycvQPuNHRoaZY2IsieMBN/5HEqGNOmXsvKf
tCg1SInO/FkE4njCxSW0R31s2KXCpgVCuq3qmoIKZobDdx7AC8GnpY1rdxUGpVoy
USJwZ2IOgtNfl/rBtOpkp/BaUCmCYOiUj13/ycDrqWvnM4TmiDdzJNEZNfez5UQp
Uvgvstoo88sewv9hGsuBWX0nC+ze/m43ZRReFhQDsypEaOw6pL2LSG9dD3tzulax
TrbPXPlN55NarQ3nmPIW
=Hj0x
-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

[Jeff Garzik]

On Fri, Jun 19, 2015 at 10:48 AM,  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
> purpose of indicating when a protocol like this is in use?
>

No.  You cannot know which is the 'right' or wrong transaction.  One tx has
obvious nSequence adjustments, the other - the refund transaction - may not.

-- 
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] F2Pool has enabled full replace-by-fee

[justusranvier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

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 
purpose of indicating when a protocol like this is in use?

As far as I know, transactions which are using those protocols can be 
easily differentiated from those that aren't (which is probably good 
from a payment assurance standpoint and bad from a privacy standpoint).

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhFW3AAoJECpf2nDq2eYjkegQAINcnzIPbO/bKqNv14TOonb8
9g/pfvMSQyZjUiu4rB6Iwtn+h1hyLkPc3cdSFV4diQSWeG7Q27ZJzH1T1kYdKp4W
DDH8DwD8PtOu+dgRK9eBsy9h72OncA4JTFhnAXMgfLVBY9eRqXk/DWlzwV/WOn/j
3G5xKKOOeHmKJCaKFwdpZghraLouS72AKSdxCNvleRc4zllV+zqWyHHssNDg7sGH
b/62O3DBZXdlzIEzK8/IeaNMY+UXd984/yQ8KCrHCKjc9uiUjNUCCw4JPo4rB/ZA
Itoc8b6pexRs8h40FdXGYAwvN5xQgcaOL7SsN2nNx/DQWYf+1krBO8Iy4kYw2KGl
8JctcHBOI2gLCxTpB2cWeGPwBQbKJhPsmxTxaTNw5fC6ycAnjoJ2bO1Uz0KfwdnI
2jmwxccB9KauC9zNthxGbvdsHOxE8foZ6AnSDI/qbYQK6MqtSnsa7BUn8vc/y4Uf
bVCsxiywVlHttCJqPh5v16rejCcH2el5Rd5PVCkEagxYFfLA3681ZJKD22UV742l
n8ii7RUJXeps6zjRAc35Ccj5qjhB4SP4qYvKmyEoltYbw1EwXbm93UCsFpuxmQ9g
GbQ/jZXsB1cmHBC+c+3X6SaU6eZdy2jDHsICP7sMx2CrZpcZZO058bqRbmdk8JE6
JI17MYG0ofTLfdCfkgEG
=en1q
-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

[Jeff Garzik]

On Fri, Jun 19, 2015 at 9:44 AM,  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 unless shown otherwise?
>

Making multiple incompatible versions of a spend is a -requirement- of
various refund contract protocols.

-- 
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] F2Pool has enabled full replace-by-fee

[Tier Nolan]

On Fri, Jun 19, 2015 at 5: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…
>

Outputs could be marked as "locked".  If you are performing a zero
confirmation spend, then the recipient could insist that you flag the
output for them as non-reducible.

This reduces privacy since it would be obvious which output was change.  If
both are locked, then the fee can't be increased.

This would be information that miners could ignore though.

Creating the right incentives is hard though.  Blocks could be
"discouraged" if they have a double spend that is known about for a while
which reduces payment for a locked output.
--
___
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: 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 signed transaction as proof of intent to pay…

Again, I'm not talking about any changes to the protocol. The mining 
mechanism in the Bitcoin protocol is the fallback method of resolving 
fraud that isn't prevented or resolved via other mechanisms.

There are plenty of other ways economic actors resolve their 
disagreements other than blockchain adjudication. Sometimes when both 
parties are identified and reside in the same legal jurisdiction, 
contract violations and fraud can be adjudicated in courts. In some 
situations, the parties involved may have access to private dispute 
resolution techniques.

Sometimes the stakeholders in the network act to preserve the long term 
value of their investments, even if it means passing short-term profits. 
The more of those stakeholders there are in Bitcoin, the more effective 
it is to make the case for choices that are long-term beneficial.

The degree to which anyone should rely on a signed transaction as 
assurance of future payment is not a question with a universal answer. 
It depends on the particular details of the situation, and the parties 
involved, and their own risk tolerances and time preferences. There's no 
right answer for everyone, which is why "let's break zeroconf because 
*I* don't think it's safe enough" is a kind of vandalism.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEkhAAoJECpf2nDq2eYj8qAP/0qYP7FJDjke1qNARGkySjC5
8fSuefu8bus/O2fNYsvPf0OcHeqepLUtQ/hgTml5AHaF1Fa9iZopVr8nZv0NFMuF
sv9RfkBKvnnrLWre3e/kQIdKzdMXompEsDwGfIeM3qvVV9AD3mKrz/YNmjs60+hU
rEdLCX8xw3ZvF3CGOzE1KnOMbADEd7i3E/Pm1n7pLVdRAg2CIU+w6mjErgucSdvB
kQ9SNAVQngjhMJyVbxsQh/+/xgecdqeZ07aaGsLhiw6zML2Tz8KMhrjJ9xw9+7h0
Gze+JdqxpgH4QrvD8KMDnlZjM+cWDUGyoVfsRvrVvPdW6kejU1r1B5Pf6dJg9TwZ
kK48RJFdd2rpAkz/kAbvQtoNMxSxhm2gKKFLEMi7g8MZUiGa/Rxj0tWL7OL9SA1U
VfpUzgAovoat9lBQM92T5vcS6kfhiNgAmF24ULGGYIhts77Ae6h8Fl3TECtnR0dM
1U1yio4Im1TfUDfjqNSK+ZjVpzkQli0R057y6XzI9HWkSYo94WyjNVoUlUozuAam
/2+tUMTrMYPeApRv+1nv13InYO8RZiFqs0E4w4TmB5V4Xt6uGUz4Olioyuo0NqMO
lBZwa1ZWKw4fLgHHDu9FhTEOXsOcX5W0gEgcoqMlzTzyoapekk9Esd0pAFLYxYMY
YQyAWtWUA4JBbgLxlB8Y
=x8eh
-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

[Peter Todd]

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 
> of intent to pay…

Indeed.

For instance, one of the ideas behind my Proofchains work is that you
could hind all details of a smartcontract-whatchamacallit protocol
behind single-use-seals in a consensus blockchain. Closing those seals,
that is spending the appropriate txouts, represents things in the
protocol which are absolutely unobservable to anyone without the data
behind those hashes, an extreme version of the above.


Incidentally, some patent prior-art exposure:

https://github.com/proofchains/python-proofchains

:)

-- 
'peter'[:-1]@petertodd.org
0a203bd78c8536399f67275064107def6c7afea29c4e3a7b


signature.asc
Description: Digital 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

[Milly Bitcoin]

"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 fascia evidence of a crime because double spend was detected 
is quite a stretch.



On 6/19/2015 12:36 PM, 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 would you automatically assume fraud by default? Shouldn't the null 
> hypothesis be the default? Without any information one way or another, you 
> ought to make *no assumption* about the fraudulence or non-fraudulence of any 
> given double-spend.
>
> --
> ___
> 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

[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 accepting zero-conf 
transactions is safe, and evidently it's going to take some harsh lessons in 
reality to correct this belief.


On Friday, 19 June 2015, at 9:42 am, 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…
> 
> 
> > On Jun 19, 2015, at 9:36 AM, 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 would you automatically assume fraud by default? Shouldn't the null 
> > hypothesis be the default? Without any information one way or another, you 
> > ought to make *no assumption* about the fraudulence or non-fraudulence of 
> > any given double-spend.
> 

--
___
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: 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 would you automatically assume fraud by default? Shouldn't the
> null hypothesis be the default? Without any information one way or
> another, you ought to make *no assumption* about the fraudulence or
> non-fraudulence of any given double-spend.

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 unless shown otherwise?

There are ways of achiving transaction fee adjustment after broadcast 
that do not present the appearance of, or opportunity for, fraud. If 
those options are available and the user chooses not to use them in 
favor of the option that does, that makes bad intentions even more 
probable.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhEasAAoJECpf2nDq2eYjcwIP/25yoRpNvZkkdFfYiBKaiL/g
XRH8iFAyM5q3/75sA23vD/fzCNGIRRWYyp8PWk+23NF1gdsgVU6gFNNCUmDbjANv
nWTt2Bd926St24jcU+OxMewSGlxpenDSFDNQVtxhNFKst6hoPatwK1Zfa0Eq7/Qw
+r0H2Pse1ulrN4P1n5xnrYMq2w/GF3zinNZbrn2KOZCnsDa8lKlP8y9eNFHBJ//Z
wDrOcfZ1WLhf5/5xlV1NiH0tdxzABilH0ITimm2LCKbj3JcSJayZlyu4n3NypE0E
cVFeYpBaVZW9wuKUv/va5fzcyWDFPAo+OrR2B3siAb8nfY1jONXNhuV3yZ76pzMr
j39lvuSpoTbLobnEWMCJQ5bI/ngbhatT57gqMfF92sO0YjMe/gi/iU6urR9fi5Gz
3Ov6QA78vxzy/YduFjkc/1FV2dNdbGJtq6b0stmz5TtM1uljeGUoj6JZ8kOJ0EXn
857KFAqEd3hG9eYtBdFQcYeV2ShndALBQE0k3cqQvV6XYdHwHuTY15i1nq+u91MZ
VwsR1M69PrDX5Ps6qo1F6QYJA/fA4fyOZ9dwIvh+cgtu4wBptr/NOpL3XH0kE2+G
b2FRGOwdb2KlejIXSL9p4mfJTX9lmk4twbZe2Spjiy4FinOUyzxEobNoUTMcFCU7
Zu2i5yjMlJzrDB8yXz/N
=xtXD
-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]

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  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 would you automatically assume fraud by default? Shouldn't the null 
> hypothesis be the default? Without any information one way or another, you 
> ought to make *no assumption* about the fraudulence or non-fraudulence of any 
> given double-spend.



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

[Peter Todd]

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 Maxwell all specifically¹ called Chainalysis's actions a sybil
> > attack.
> >
> > The Bitcoin P2P network is resilliant to failure when the chance of any
> > one node going down is uncorrelated with others. For instance if you
> > accidentally introduced a bug in your nodes that failed to relay
> > transactions/blocks properly, you'd simultaneously be disrupting a large
> > portion of the network all at once.
> >
> 
> This is exactly what your RBF patch is doing. By your own logic, nodes on
> the network should be allowed to relay (or not relay) whatever they wish.

Ah, seems you misunderstand the problem.

By properly we're concerned that things do get relayed, not that they do
not. In particularl with blocks a fairly to relay valid blocks will
quickly lead to a loss of consensus.

> > How many nodes is Coinbase connecting too? What software are they
> > running? What subnets are they using? In particular, are they all on one
> > subnet or multiple?
> >
> 
> We're running about a dozen nodes running regular Bitcoin Core in various
> subnets. We aren't doing anything particularly out of the ordinary here.
> Nothing that would fall under your definition of a sybil attack or harmful
> to the network.

Right, so those dozen nodes, how many outgoing connections are they
making?

> > But of course, you'd never 51% the network right? After all it's not
> > possible to guarantee that your miner won't mine double-spends, as there
> > is no single consensus definition of which transaction came first, nor
> > can there be.
> >
> > Or do you see things differently? If I'm a small miner should I be
> > worried my blocks might be rejected by the majority with hashing power
> > contracts because I'm unable to predict which transactions Coinbase
> > believes should go in the blockchain?
> >
> 
> You seem so concerned that we are actively trying to harm or control the
> network. We're simply trying to drive bitcoin adoption by making it easy
> for people to spend their bitcoin with merchants online. The problems we
> face are no different from other merchant processors, or small independent
> merchants accepting online or point-of-sale payments.
>
> We've historically had relatively little interest in what miners were doing
> (until RBF came out) - for the most part it didn't affect our business.
> However, most large merchants would be simply uninterested in accepting
> bitcoin if we forced their customers to wait 10-60 minutes for their
> payments to confirm. Many have inventory management systems which can not
> even place items on hold that long.

While your goals may be reasonable, again, the question is how are you
going to achieve them? Do you accept that you may be in a position where
you can't guarantee confirmations? Again, what's your plan to deal with
this? For instance, I know Coinbase is contractually obliged to accept
zeroconf payments with at least some of your customers - how strong are
those agreements?

What we're worried about is your plan appears to include nothing
concrete beyond the possibility of getting contracts with hashing power,
maybe even just a majority of hashing power. This is something that
should concern everyone in the Bitcoin ecosystem, and it'd help if you
clearly stated what your intentions are.

-- 
'peter'[:-1]@petertodd.org
1128683847671e0ca022f9c74df90a3dc718545379101b72


signature.asc
Description: Digital 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

[Matt Whitlock]

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? Without any information one way or another, you 
ought to make *no assumption* about the fraudulence or non-fraudulence of any 
given double-spend.

--
___
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

[Adrian Macneil]

>
> > 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
> attack.
>
> The Bitcoin P2P network is resilliant to failure when the chance of any
> one node going down is uncorrelated with others. For instance if you
> accidentally introduced a bug in your nodes that failed to relay
> transactions/blocks properly, you'd simultaneously be disrupting a large
> portion of the network all at once.
>

This is exactly what your RBF patch is doing. By your own logic, nodes on
the network should be allowed to relay (or not relay) whatever they wish.


> How many nodes is Coinbase connecting too? What software are they
> running? What subnets are they using? In particular, are they all on one
> subnet or multiple?
>

We're running about a dozen nodes running regular Bitcoin Core in various
subnets. We aren't doing anything particularly out of the ordinary here.
Nothing that would fall under your definition of a sybil attack or harmful
to the network.

> > You know, you're creating an interesting bit of game theory here: if I'm
> > > a miner who doesn't already have a mining contract, why not implement
> > > full-RBF to force Coinbase to offer me one? One reason might be because
> > > other miners with such a contract - a majority - are going to be asked
> > > by Coinbase to reorg you out of the blockchain, but then we have a
> > > situation where a single entity has control of the blockchain.
> > >
> >
> > If someone did enter into contracts with miners to mine certain
> > transactions, and had a guarantee that the miners would not build on
> > previous blocks which included double spends, then they would only need
> > contracts with 51% of the network anyway. So it wouldn't really matter if
> > you were a small time miner and wanted to run full-RBF.
>
> But of course, you'd never 51% the network right? After all it's not
> possible to guarantee that your miner won't mine double-spends, as there
> is no single consensus definition of which transaction came first, nor
> can there be.
>
> Or do you see things differently? If I'm a small miner should I be
> worried my blocks might be rejected by the majority with hashing power
> contracts because I'm unable to predict which transactions Coinbase
> believes should go in the blockchain?
>

You seem so concerned that we are actively trying to harm or control the
network. We're simply trying to drive bitcoin adoption by making it easy
for people to spend their bitcoin with merchants online. The problems we
face are no different from other merchant processors, or small independent
merchants accepting online or point-of-sale payments.

We've historically had relatively little interest in what miners were doing
(until RBF came out) - for the most part it didn't affect our business.
However, most large merchants would be simply uninterested in accepting
bitcoin if we forced their customers to wait 10-60 minutes for their
payments to confirm. Many have inventory management systems which can not
even place items on hold that long.

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. I do not see a single benefit
to running full-RBF.

FWIW, I'm fine with the first-seen-safe RBF, that seems like a sensible
addition and a good way to allow fees to be added or increased on existing
transactions, without harming existing applications of bitcoin.

Adrian
--
___
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

[Peter Todd]

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 supporting full RBF over FSS RBF would likely be
> > negligible. Did they consider using FSS RBF instead?
> 
> Specifically the following is what I told them:

Incidentally, because someone asked that message was sent two weeks ago.


Also, a shout-out to Marshal Long of FinalHash for his help with
(FSS)-RBF deployment and for getting F2Pool and myself in touch, as well
as his work in talking getting pools on board with BIP66.

-- 
'peter'[:-1]@petertodd.org
0bb4abd88c6b023e9f19a1c1deaac120467279c330a803cf


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

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Milly Bitcoin]

 >- Did you accept payment from companies to lobby for 20MB blocks? Do 
you consider that something appropriate to publicly disclose if so? Do 
you consider that user rights should come above or below company 
interests in Bitcoin? FWIW on pondering that last question "should user 
rights come above or below company interests" I think my view of the 
guiding principle is starkly clear to me: that user rights should be the 
primary thing to optimise for. Businesses are providing service to 
users, their interests are secondary in so far as if they are enabled to 
provide better service thats good. Bitcoin is a user p2p currency, with 
a social contract and a strong user ethos. Importing and forcing company 
interests would likely be the start of a slippery slope towards an end 
to Bitcoin.

I always thought is was the exact opposite.  I thought it was expected 
that the only incentive for developers (other than increasing the value 
of coins they hold) is to lobby for changes that will benefit the 
companies that fund them.  That is the only way you are going to get 
more full time developers on board.  It focuses their efforts on  
products and services people want rather than some sort philosophical 
agenda that may be unrealistic.  The notion that large numbers of 
volunteers will do all this work at little or no pay to improve user 
experience is not a realistic long term plan.  I also think it is 
incorrect to assume some kind of "social contract" and "strong user 
ethos."  While many early users are like that I think most potential 
users of Bitcoin don't think that way.

Russ




--
___
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: 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 relaxing this assumption
> without adequately assessing the risk (i.e. I’ve never been hacked
> before so I can assume it’s safe) is extremely dangerous at best and
> just horrid security practice at worst. Your users might not thank you
> for not getting hacked - but they surely will not like it when you DO
> get hacked…and lack a proper recovery plan.
> 
> Furthermore, the protocol itself makes no assumptions regarding the
> intentions behind someone signing two conflicting transactions. There
> are many potential use cases where doing so could make a lot of sense.
> Had the protocol been designed along the lines of, say,
> tendermint…where signing multiple conflicting blocks results in loss
> of one’s funds…then the protocol itself disincentivizes the behavior
> without requiring any sort of altruistic, moralistic assumptions. That
> would also mean we’d need a different mechanism for the use cases that
> things like RBF address.
> 
> Thirdly, taken to the extreme, the viewpoint of “signing a conflicting
> transaction is fraud and vandalism” means that if for whatever reason
> you attempt to propagate a transaction and nobody mines it for a very
> long time, you’re not entitled to immediately reclaim those funds…they
> must remain in limbo forever.

I'm not talking about changing the protocol - I'm talking about the 
business relationships between users of Bitcoin.

I would expect a payment processor to inform the merchants of relevant 
double spends that it observes on the network, even if the payment is 
actually successful, so that the merchant can decide for themselves 
whether or not to pursue it out of band.

Mining is a kind of technical fallback that allows the network to 
resolve human misbehavior without human intervention. If nobody ever 
attempted to make a fraudulent payment, we wouldn't need mining at all 
because the signed transaction itself is proof of intention to pay. That 
it exists doesn't suddenly make fraud less fraudulent and mean that 
users who are in a position to pursue out of band recourse shouldn't do 
so.

I agree that there are valid reasons for replacing transactions in the 
mempool, I just think they should be implemented in a way that doesn't 
facilitate fraud.

I'd also like to note that "prima facie" doesn't mean "always", it means 
that "the default assumption, unless proven otherwise."

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDqcAAoJECpf2nDq2eYjX/UP/RlVIGqzwvdKftFW8kRW1+Dk
3befE2vEIEWFAShNt0pk7/Isqk7prRWQDKP+VNZSJfaoyE3akOe7s3OPWuevVRqM
Y1N658hYnG6NPebkyp5zUQkjT3mXVxOo9Fw9k7JyHgkWaDcwx330z2n6yztleodq
7hlKdW6sZrgqHw+DoF0Zal3QPN0WYm0XAno3uy71RXOs5cAoUxViuVzWHY0oReTQ
uggTggT1A5acmyOM7v65h9Cb2AKcLvHKfSEIwVQbHxYMOT+3GIJOXPKAluh8MjB3
oWg8ERy5dEEHu5kF/MLPQMg5yVQACuQmO2dlmtRoOs3mUQQj+q7dEil/dZMIp0f+
unDKIwLhXMa0sZ+63123UOgaKGZkF7afed3ueniJWQM80VS0WoZvZYhQadT/sCED
Ntfxifi1ZqCiKFeshyN9z7jDC8QEJ3N176Kr/wX76h/vvnPYicMEcfRgSE8EGd10
+oRQQpYzb69WPSFRhhrR3yG9Dev1JfzNPEaIKKYerDk9Vo3OnQ3VaaqBNZwBDo46
4r3O5orFES/ZxMdzWE1cWp99n4T4L6KxdZXmfQSYHehUJBnt62vKuEk9X/Li2ZWo
i3dr3yxx8xhKGGjsSjG03arz70bkXE7SvrICPOs9OEAdGlJI2liLrSWzYU9BbTle
eWvElyVQJsJHgAU8ygvn
=77NP
-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

[Jeff Garzik]

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 how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
> On Fri, Jun 19, 2015 at 9:44 PM, 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 supporting full RBF over FSS RBF would likely be
> >> negligible. Did they consider using FSS RBF instead?
> >
> > Specifically the following is what I told them:
> >
> >> We are
> >> interested in the replace-by-fee patch, but I am not following the
> >> development closely, more background info is needed, like what the
> >> difference between standard and zeroconf versions? Thanks.
> >
> > Great!
> >
> > Basically both let you replace one transaction with another that pays a
> > higher fee. First-seen-safe replace-by-fee adds the additional criteria
> > that all outputs of the old transaction still need to be paid by the new
> > transaction, with >= as many Bitcoins. Basically, it makes sure that if
> > someone was paid by tx1, then tx2 will still pay them.
> >
> > I've written about how wallets can use RBF and FSS-RBF to more
> > efficiently use the blockchain on the bitcoin-development mailing list:
> >
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
> >
> > Basically, for the purpose of increasing fees, RBF is something like %50
> > cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
> >
> > In addition, for ease of implementation, my new FSS-RBF has a number of
> > other restrictions. For instance, you can't replace multiple
> > transactions with one, you can't replace a transaction whose outputs
> > have already been spent, you can't replace a transaction with one that
> > spends additional unconfirmed inputs, etc. These restrictions aren't
> > "set in stone", but they do make the code simpler and less likely to
> > have bugs.
> >
> > In comparison my previous standard RBF patch can replace multiple
> > transactions with one, can replace long chains of transactions, etc.
> > It's willing to do more computation before deciding if a transaction
> > should be replaced, with more complex logic; it probably has a higher
> > chance of having a bug or DoS attack.
> >
> > You've probably seen the huge controversy around zeroconf with regard to
> > standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
> > it also doesn't make it any more dangerous, so politically with regard
> > to zeroconf it makes no difference. You *can* still use it doublespend
> > by taking advantage of how different transactions are accepted
> > differently, but that's true of *every* change we've ever made to
> > Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
> > zeroconf in the same way.
> >
> >
> > 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
> > supporting miners to figure out what transactions are being mined, are
> > services having any hope of avoiding getting ripped off. For the average
> > user their wallets do a terrible job of showing whether or not an
> > unconfirmed transaction will go through. For example, Schildbach's
> > Bitcoin wallet for Android has no code at all to detect double-spends
> > until they get mined, and I've been able to trick it into showing
> > completely invalid transactions. In fact, currently Bitcoin XT will
> > relay invalid transactions that are doublepsends, and Schildbach's
> > wallet displays them as valid, unconfirmed, payments. It's really no
> > surprise to me that nearly no-one in the Bitcoin ecosystem accepts
> > unconfirmed transactions without some kind of protection that doesn't
> > rely on first-seen-safe mempool behavior. For instance, many ATM's these
> > days know who their customers are due to AML requirements, so while you
> > can deposit Bitcoins and get your funds instantly, the protection for
> > the ATM operator is that they can go to the police if you rip them off;
> > I've spoken to ATM operators who didn't do this who've lost hundreds or
> > even thousands of dollars before giving up on zeroconf.
> >
> > My big worry with zeroconf is a service like Coinbase or Shapeshift
> > coming to rely on it, and then attempting to secure it by gaining
> > control of a majority of hashing power. For instance, if Coinbase had
> > contracts with 80% of the 

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

[Jeff Garzik]

On Fri, Jun 19, 2015 at 6:44 AM, Peter Todd  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
> supporting miners to figure out what transactions are being mined, are
> services having any hope of avoiding getting ripped off. For the average
> user their wallets do a terrible job of showing whether or not an
>

This is no excuse for further degrading the overall network security.

There are many issues to address in the bitcoin ecosystem.  It negatively
impacts users to roll out "scorched earth" replace-by-fee given today's
ecosystem.

Yes, zero conf security is poor.  An outright attack on zero conf degrades
user security even more.

-- 
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] F2Pool has enabled full replace-by-fee

[Peter Todd]

On Fri, Jun 19, 2015 at 08:20:52AM -0700, Adrian Macneil wrote:
> >
> > 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 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
attack.

The Bitcoin P2P network is resilliant to failure when the chance of any
one node going down is uncorrelated with others. For instance if you
accidentally introduced a bug in your nodes that failed to relay
transactions/blocks properly, you'd simultaneously be disrupting a large
portion of the network all at once.

How many nodes is Coinbase connecting too? What software are they
running? What subnets are they using? In particular, are they all on one
subnet or multiple?

> but relaying harmful double spend transactions just because you can and
> it's not technically prevented, is good for everyone?

You realise that Hearn/Andresen/Harding's double-spend-relaying patch,
included in Bitcoin XT, relays double-spend transactions right? Do you
consider that harmful?

> > You know, you're creating an interesting bit of game theory here: if I'm
> > a miner who doesn't already have a mining contract, why not implement
> > full-RBF to force Coinbase to offer me one? One reason might be because
> > other miners with such a contract - a majority - are going to be asked
> > by Coinbase to reorg you out of the blockchain, but then we have a
> > situation where a single entity has control of the blockchain.
> >
> 
> If someone did enter into contracts with miners to mine certain
> transactions, and had a guarantee that the miners would not build on
> previous blocks which included double spends, then they would only need
> contracts with 51% of the network anyway. So it wouldn't really matter if
> you were a small time miner and wanted to run full-RBF.

But of course, you'd never 51% the network right? After all it's not
possible to guarantee that your miner won't mine double-spends, as there
is no single consensus definition of which transaction came first, nor
can there be.

Or do you see things differently? If I'm a small miner should I be
worried my blocks might be rejected by the majority with hashing power
contracts because I'm unable to predict which transactions Coinbase
believes should go in the blockchain?

> > For the good of Bitcoin, and your own company, you'd do well to firmly
> > state that under no condition will Coinbase ever enter into mining
> > contracts.
> >
> 
> I don't personally see what good this does for bitcoin. Now you are
> suggesting that we should prevent a 51% attack by using policy and
> promises, rather than a technical solution. How is this any better than us
> relying on existing double spend rules which are based on policy and
> promises?

Well, I think I've shown how dangerous mining contracts can be to the
overall health of the Bitcoin ecosystem; I'm simply asking you to
promise not to make use of this dangerous option regardless of what
happens. Like I said, if for whatever reason the first-seen mempool
behavior proves to be insufficient at preventing double-spends from your
perspective, you did suggest you might use mining contracts to ensure
txs you want mined get mined, over others.


1) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
   March 14th 2015, Grace Caffyn, Coindesk,
   
http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-bitcoin-network/

-- 
'peter'[:-1]@petertodd.org
0e806870e7e9cf4d507af6b78fc709e6839a8d34b52ea334


signature.asc
Description: Digital 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

[Jeff Garzik]

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
indicated by the following code change:
https://github.com/bitcoin/bitcoin/pull/6176


On Fri, Jun 19, 2015 at 3: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 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 Andre

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

[justusranvier]

-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
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
> 
> Yet from the point of view of an external observer they have no idea 
> why
> the transaction outputs reduced in size, nor any way of knowing if 
> fraud
> did or did not occur.

If there are two transactions which spend the same inputs, and each 
transaction has completely different output scripts, then this is prima 
facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie

If the two transactions have identical output scripts, and one output is 
reduced in value to increase the transaction fee, that has the 
appearance of honest dealing. There is a possibility that the payer has 
chose to under-pay their payee in order to over-pay the miner, but 
that's not what a reasonable observer would assume at first glance.

Adding outputs to a transaction, while keeping all the existing outputs 
exactly how they are is another way of increasing the transaction fee of 
a transaction and is prima facie non-fraudulent.

Note that child-pays-for-parent has none of this ambiguity.

> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?

I haven't closely looked into the features of Bitcoin XT because I'm 
hoping that it never becomes relevant. I do want to see a heterogenous 
implementation network develop, but Bitcoin XT doesn't really count 
since it's a derivative of the Bitcoin Core codebase.

In general, I think every signed Bitcoin transaction sent between 
different parties is part of a valid, enforceable contract (using common 
law definitions which predate any particular legal jurisdiction). 
Handling contracts and money is Serious Business and so the decision of 
how software should respond to double spends should not be made 
frivolously.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1
7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG
yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ
4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A
Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ
dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m
Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH
NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7
xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE
vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u
8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl
uEW4Vcn+HxlNI/rhxBw4
=odRL
-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]

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 before so I can assume it’s safe) is 
extremely dangerous at best and just horrid security practice at worst. Your 
users might not thank you for not getting hacked - but they surely will not 
like it when you DO get hacked…and lack a proper recovery plan.

Furthermore, the protocol itself makes no assumptions regarding the intentions 
behind someone signing two conflicting transactions. There are many potential 
use cases where doing so could make a lot of sense. Had the protocol been 
designed along the lines of, say, tendermint…where signing multiple conflicting 
blocks results in loss of one’s funds…then the protocol itself disincentivizes 
the behavior without requiring any sort of altruistic, moralistic assumptions. 
That would also mean we’d need a different mechanism for the use cases that 
things like RBF address.

Thirdly, taken to the extreme, the viewpoint of “signing a conflicting 
transaction is fraud and vandalism” means that if for whatever reason you 
attempt to propagate a transaction and nobody mines it for a very long time, 
you’re not entitled to immediately reclaim those funds…they must remain in 
limbo forever.


- Eric Lombrozo


> On Jun 19, 2015, at 8:11 AM, Peter Todd  wrote:
> 
> 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 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.
>> 
>> 
>> Intentional fraud is a bad thing to add to a financial protocol.
>> 
>> A user who creates conflicting transactions, one that pays someone else
>> and another which does not pay them, and broadcasts both of them, has
>> just self-incriminated themselves by producing prima facie evidence of
>> fraud.
> 
> Depends.
> 
> 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
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
> 
> Yet from the point of view of an external observer they have no idea why
> the transaction outputs reduced in size, nor any way of knowing if fraud
> did or did not occur.
> 
> Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
> that debt", in which case I'm not breaking any contract at all by giving
> you less money than I first promised - the contract has changed.
> 
> Again, none of this can or should be observable to anyone other than the
> parties directly involved.
> 
>> It may be the case that since Bitcoin spans multiple legal jurisdictions
>> and can be use anonymously that the victims of such fraud can not rely
>> on legal recourse, and it may also be the case that proof of work is how
>> Bitcoin deals with the aforementioned factors, but regardless
>> un-prosecutable fraud is still fraud and anyone who encourages it should
>> be recognied as a bad actors.
>> 
>> Committing vandalism and encouraging fraud to prove a point may be
>> something the network can't stop on a technical level, but there's no
>> reason not to call it out for what it is.
> 
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
> 
> --
> 'peter'[:-1]@petertodd.org
> 03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



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

[Adrian Macneil]

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 
> 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
> > as a way to prevent fraud.
>
> This might be useful to you: https://www.f2pool.com/api/mempool
>
>
--
___
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

[Adrian Macneil]

>
> 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 technically
prevented is bad for the network and creating systemic risks of failure,
but relaying harmful double spend transactions just because you can and
it's not technically prevented, is good for everyone?


> You know, you're creating an interesting bit of game theory here: if I'm
> a miner who doesn't already have a mining contract, why not implement
> full-RBF to force Coinbase to offer me one? One reason might be because
> other miners with such a contract - a majority - are going to be asked
> by Coinbase to reorg you out of the blockchain, but then we have a
> situation where a single entity has control of the blockchain.
>

If someone did enter into contracts with miners to mine certain
transactions, and had a guarantee that the miners would not build on
previous blocks which included double spends, then they would only need
contracts with 51% of the network anyway. So it wouldn't really matter if
you were a small time miner and wanted to run full-RBF.


> For the good of Bitcoin, and your own company, you'd do well to firmly
> state that under no condition will Coinbase ever enter into mining
> contracts.
>

I don't personally see what good this does for bitcoin. Now you are
suggesting that we should prevent a 51% attack by using policy and
promises, rather than a technical solution. How is this any better than us
relying on existing double spend rules which are based on policy and
promises?
--
___
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

[Peter Todd]

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 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.
> 
> 
> Intentional fraud is a bad thing to add to a financial protocol.
> 
> A user who creates conflicting transactions, one that pays someone else 
> and another which does not pay them, and broadcasts both of them, has 
> just self-incriminated themselves by producing prima facie evidence of 
> fraud.

Depends.

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
defrauding you, I'm just reducing the value of my change address to pay
a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.

Yet from the point of view of an external observer they have no idea why
the transaction outputs reduced in size, nor any way of knowing if fraud
did or did not occur.

Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
that debt", in which case I'm not breaking any contract at all by giving
you less money than I first promised - the contract has changed.

Again, none of this can or should be observable to anyone other than the
parties directly involved.

> It may be the case that since Bitcoin spans multiple legal jurisdictions 
> and can be use anonymously that the victims of such fraud can not rely 
> on legal recourse, and it may also be the case that proof of work is how 
> Bitcoin deals with the aforementioned factors, but regardless 
> un-prosecutable fraud is still fraud and anyone who encourages it should 
> be recognied as a bad actors.
> 
> Committing vandalism and encouraging fraud to prove a point may be 
> something the network can't stop on a technical level, but there's no 
> reason not to call it out for what it is.

What do you think of Bitcoin XT then? It relays double-spends, which
makes it much easier to get double-spends to miners than before. In
particular you see a lot of zero-fee transactions being replaced by
fee-paying transactions, relayed through Bitcoin XT nodes and then
mined. Is that encouraging fraud?

-- 
'peter'[:-1]@petertodd.org
03932458055c68d4ee2b6d68441c4764efbdf6b0b1683717


signature.asc
Description: Digital 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

[justusranvier]

-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 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.


Intentional fraud is a bad thing to add to a financial protocol.

A user who creates conflicting transactions, one that pays someone else 
and another which does not pay them, and broadcasts both of them, has 
just self-incriminated themselves by producing prima facie evidence of 
fraud.

It may be the case that since Bitcoin spans multiple legal jurisdictions 
and can be use anonymously that the victims of such fraud can not rely 
on legal recourse, and it may also be the case that proof of work is how 
Bitcoin deals with the aforementioned factors, but regardless 
un-prosecutable fraud is still fraud and anyone who encourages it should 
be recognied as a bad actors.

Committing vandalism and encouraging fraud to prove a point may be 
something the network can't stop on a technical level, but there's no 
reason not to call it out for what it is.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVhCsXAAoJECpf2nDq2eYjA08P/ApDFcIGws55TsgDFxPhDpN+
Iq9a06mPbXVjUfRxP5ZwmJuiM+XzHQ4QL3C2BH0OETatIV+bh7GP2mGHPcUAISYt
1j4TKhurnC+mqN+YAsiI5hQsws8DvPYXBTYYn0savaJTbq6/Q77+xvfRgNxofcPW
EHpnl/5wcmYGgp3mVyStGJ+qIP17yywzCLnSA3WEPaZG/9/FPrIq3Ptw2+RHod79
nzDiFBiKLK8E5NPbdbXS+gkjkkBA/QeCzZObpMOeWMriu/PIifVi8KssLSznnEwx
r7hiv6ISW47BTzkRbjxmXmGep3wfl8MjH7BZq3g0uyiApMdmjohIJ2lyuvOXdh7s
47+4r2xA8gG+z0aQTmCx5TS75T0Hnj3I78ZtCVr31Ip2OLbNI1mQ2gPR2zaoZkUZ
atp2XCssHDlY2s30k5hAnIHxuN6CkyGkZCECSuv46Z3ok6ll/nIP80qB7BBzVlP1
xfSOPZh57J31U8PxZBZcwgdRg+HBiExvg484grE+h18izxcrjNfPRSWP4+7nEZtK
LN7JL7YcmhVfhqKTSd6+C4bD2LsKsrcMiUhH1xHkD/hzAxc7egL6lgYTHJjU+yPu
BTIh0VHJxBgroHB45Vq6loa4B3l4ZCl4Ykw8Opm7NJIfueJ0l0ySyJXi6ix4bjVf
ZRF0Ot9RP0M0fHEwOpT6
=s0w/
-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

[Peter Todd]

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
> double spend a small fraction of the time, it's an acceptable cost to us in
> exchange for being able to provide a fast checkout experience to customers
> and merchants.

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.

You realise how the fact that F2Pool is using full-RBF right now does
strongly suggest that the chances of a double-spend are not only low,
but more importantly, vary greatly? Any small change in relaying policy
or even network conditions creates opportunities to double-spend.

> If the status quo changes, then we will need to investigate alternatives
> (which realistically would include mining contracts, or only accepting
> instant payments from other trusted hosted wallets, which would be a net
> loss for decentralization).

You know, you're creating an interesting bit of game theory here: if I'm
a miner who doesn't already have a mining contract, why not implement
full-RBF to force Coinbase to offer me one? One reason might be because
other miners with such a contract - a majority - are going to be asked
by Coinbase to reorg you out of the blockchain, but then we have a
situation where a single entity has control of the blockchain.

For the good of Bitcoin, and your own company, you'd do well to firmly
state that under no condition will Coinbase ever enter into mining
contracts.

-- 
'peter'[:-1]@petertodd.org
0fe727215265d9ddacb2930ad2d45920b71920b7aed687f1


signature.asc
Description: Digital 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

[Chun Wang]

On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil  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
> as a way to prevent fraud.

This might be useful to you: https://www.f2pool.com/api/mempool

--
___
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

[Adrian Macneil]

>
> > 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
> > this as a way to prevent fraud.
>
> What happens if the mining pools who are mining double-spends aren't
> doing it delibrately? Sybil attacking pools appears to have been done
> before to get double-spends though, equally there are many other changes
> the reduce the reliability of transaction confirmations. For instance
> the higher demands on bandwidth of a higher blocksize will inevitably
> reduce the syncronicity of mempools, resulting in double-spend
> opportunities. Similarly many proposals to limit mempool size allow
> zeroconf double-spends.
>
> 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
double spend a small fraction of the time, it's an acceptable cost to us in
exchange for being able to provide a fast checkout experience to customers
and merchants.

If the status quo changes, then we will need to investigate alternatives
(which realistically would include mining contracts, or only accepting
instant payments from other trusted hosted wallets, which would be a net
loss for decentralization).

Long term we would prefer to see an open, decentralized solution, such as
payment channels / green addresses / lightening networks. However, I think
as a community we are a long way away from choosing a standard here and
implementing it across all popular wallet software and merchant processors.

Adrian
--
___
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

[Lawrence Nahum]

Chun Wang <1240902  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 think FSS RBF is  great progress but ultimately less efficient and more 
complicated to keep alive something that never worked properly.

And why would miner pick the option paying less when other miners run the 
option paying more? It may be soon more than 1-5% of block reward.

A lot of users don't have multiple UTXO handy.

Full RBF is the best, second FSS RBF and we'd be looking into supporting 
them both separately so that miners and users can pick whichever they 
prefer.

If users only had one UTXO it makes sense to use Full RBF since there are no 
other options.

Disclosure: GreenAddress always believed zero conf transactions are not 
secure and that miners have the incentive to run FBF; this bias doesn't make 
the above less true 



--
___
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

[Peter Todd]

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 could be for the
> > 80% to not build on blocks containing doublespends by the 20%.
> >
> 
> This seems to be more of a problem with centralized mining than zeroconf
> transactions.

You're mistaking cause and effect: the contracts will drive
centralization of mining, as only the larger, non-anonymous, players
have the ability to enter into such contracts.

> Speaking of, could we get a confirmation that Coinbase is, or is not,
> > one of the merchant service providers trying to get hashing power
> > contracts with mining pools for guaranteed transaction acceptance? IIRC
> > you are still an advisor to them. This is a serious concern for the
> > reasons I outlined in my post.
> >
> 
> 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
> this as a way to prevent fraud.

What happens if the mining pools who are mining double-spends aren't
doing it delibrately? Sybil attacking pools appears to have been done
before to get double-spends though, equally there are many other changes
the reduce the reliability of transaction confirmations. For instance
the higher demands on bandwidth of a higher blocksize will inevitably
reduce the syncronicity of mempools, resulting in double-spend
opportunities. Similarly many proposals to limit mempool size allow
zeroconf double-spends.

In that case would you enter into such contracts?

-- 
'peter'[:-1]@petertodd.org
05a4c76d0bf088ef3e059914d6fc0335683a92b5be01b7dc


signature.asc
Description: Digital 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

[Adrian Macneil]

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
overall utility of bitcoin and reduce the number of people using it for
online purchases.

Adrian




On Fri, Jun 19, 2015 at 6:33 AM, 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 they consider using FSS RBF instead?
>
> Best,
> Stephen
>
> On Fri, Jun 19, 2015 at 6: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

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

[Adrian Macneil]

>
> 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 the 20%.
>

This seems to be more of a problem with centralized mining than zeroconf
transactions.

Speaking of, could we get a confirmation that Coinbase is, or is not,
> one of the merchant service providers trying to get hashing power
> contracts with mining pools for guaranteed transaction acceptance? IIRC
> you are still an advisor to them. This is a serious concern for the
> reasons I outlined in my post.
>

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
this as a way to prevent fraud.

In the long term, I would love to see a safe, decentralized solution for
accepting zeroconf transactions. However, right now there is no such
solution supported by any wallets in use, and I don't think breaking the
current bitcoin behavior for everyone is the best way to achieve this.

Adrian
--
___
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

[Chun Wang]

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 at 9:44 PM, 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 supporting full RBF over FSS RBF would likely be
>> negligible. Did they consider using FSS RBF instead?
>
> Specifically the following is what I told them:
>
>> We are
>> interested in the replace-by-fee patch, but I am not following the
>> development closely, more background info is needed, like what the
>> difference between standard and zeroconf versions? Thanks.
>
> Great!
>
> Basically both let you replace one transaction with another that pays a
> higher fee. First-seen-safe replace-by-fee adds the additional criteria
> that all outputs of the old transaction still need to be paid by the new
> transaction, with >= as many Bitcoins. Basically, it makes sure that if
> someone was paid by tx1, then tx2 will still pay them.
>
> I've written about how wallets can use RBF and FSS-RBF to more
> efficiently use the blockchain on the bitcoin-development mailing list:
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
>
> Basically, for the purpose of increasing fees, RBF is something like %50
> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>
> In addition, for ease of implementation, my new FSS-RBF has a number of
> other restrictions. For instance, you can't replace multiple
> transactions with one, you can't replace a transaction whose outputs
> have already been spent, you can't replace a transaction with one that
> spends additional unconfirmed inputs, etc. These restrictions aren't
> "set in stone", but they do make the code simpler and less likely to
> have bugs.
>
> In comparison my previous standard RBF patch can replace multiple
> transactions with one, can replace long chains of transactions, etc.
> It's willing to do more computation before deciding if a transaction
> should be replaced, with more complex logic; it probably has a higher
> chance of having a bug or DoS attack.
>
> You've probably seen the huge controversy around zeroconf with regard to
> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
> it also doesn't make it any more dangerous, so politically with regard
> to zeroconf it makes no difference. You *can* still use it doublespend
> by taking advantage of how different transactions are accepted
> differently, but that's true of *every* change we've ever made to
> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
> zeroconf in the same way.
>
>
> 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
> supporting miners to figure out what transactions are being mined, are
> services having any hope of avoiding getting ripped off. For the average
> user their wallets do a terrible job of showing whether or not an
> unconfirmed transaction will go through. For example, Schildbach's
> Bitcoin wallet for Android has no code at all to detect double-spends
> until they get mined, and I've been able to trick it into showing
> completely invalid transactions. In fact, currently Bitcoin XT will
> relay invalid transactions that are doublepsends, and Schildbach's
> wallet displays them as valid, unconfirmed, payments. It's really no
> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
> unconfirmed transactions without some kind of protection that doesn't
> rely on first-seen-safe mempool behavior. For instance, many ATM's these
> days know who their customers are due to AML requirements, so while you
> can deposit Bitcoins and get your funds instantly, the protection for
> the ATM operator is that they can go to the police if you rip them off;
> I've spoken to ATM operators who didn't do this who've lost hundreds or
> even thousands of dollars before giving up on zeroconf.
>
> My big worry with zeroconf is a service like Coinbase or Shapeshift
> coming to rely on it, and then attempting to secure it by gaining
> control of a majority of hashing power. 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 the 20%. There's
> no way in a dece

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

[Peter Todd]

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
> replace-by-fee before doing that, because until that happens replace-by-fee
> just makes it easier to steal from bitcoin-accepting merchants.

Do you mean just full-RBF, or FSS-RBF as well?


Speaking of, could we get a confirmation that Coinbase is, or is not,
one of the merchant service providers trying to get hashing power
contracts with mining pools for guaranteed transaction acceptance? IIRC
you are still an advisor to them. This is a serious concern for the
reasons I outlined in my post.

Equally if anyone else from Coinbase would like to chime in that'd be
great.

-- 
'peter'[:-1]@petertodd.org
0d7110f3a176228445ed710afd332291384992ed89c5c1a7


signature.asc
Description: Digital 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

[Peter Todd]

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 step forward for Bitcoin.

-- 
'peter'[:-1]@petertodd.org
03188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab


signature.asc
Description: Digital 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

[Peter Todd]

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 they consider using FSS RBF instead?

Specifically the following is what I told them:

> We are
> interested in the replace-by-fee patch, but I am not following the
> development closely, more background info is needed, like what the
> difference between standard and zeroconf versions? Thanks.

Great!

Basically both let you replace one transaction with another that pays a
higher fee. First-seen-safe replace-by-fee adds the additional criteria
that all outputs of the old transaction still need to be paid by the new
transaction, with >= as many Bitcoins. Basically, it makes sure that if
someone was paid by tx1, then tx2 will still pay them.

I've written about how wallets can use RBF and FSS-RBF to more
efficiently use the blockchain on the bitcoin-development mailing list:

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html

Basically, for the purpose of increasing fees, RBF is something like %50
cheaper than CPFP, and FSS-RBF is something like %25 cheaper.

In addition, for ease of implementation, my new FSS-RBF has a number of
other restrictions. For instance, you can't replace multiple
transactions with one, you can't replace a transaction whose outputs
have already been spent, you can't replace a transaction with one that
spends additional unconfirmed inputs, etc. These restrictions aren't
"set in stone", but they do make the code simpler and less likely to
have bugs.

In comparison my previous standard RBF patch can replace multiple
transactions with one, can replace long chains of transactions, etc.
It's willing to do more computation before deciding if a transaction
should be replaced, with more complex logic; it probably has a higher
chance of having a bug or DoS attack.

You've probably seen the huge controversy around zeroconf with regard to
standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
it also doesn't make it any more dangerous, so politically with regard
to zeroconf it makes no difference. You *can* still use it doublespend
by taking advantage of how different transactions are accepted
differently, but that's true of *every* change we've ever made to
Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
zeroconf in the same way.


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
supporting miners to figure out what transactions are being mined, are
services having any hope of avoiding getting ripped off. For the average
user their wallets do a terrible job of showing whether or not an
unconfirmed transaction will go through. For example, Schildbach's
Bitcoin wallet for Android has no code at all to detect double-spends
until they get mined, and I've been able to trick it into showing
completely invalid transactions. In fact, currently Bitcoin XT will
relay invalid transactions that are doublepsends, and Schildbach's
wallet displays them as valid, unconfirmed, payments. It's really no
surprise to me that nearly no-one in the Bitcoin ecosystem accepts
unconfirmed transactions without some kind of protection that doesn't
rely on first-seen-safe mempool behavior. For instance, many ATM's these
days know who their customers are due to AML requirements, so while you
can deposit Bitcoins and get your funds instantly, the protection for
the ATM operator is that they can go to the police if you rip them off;
I've spoken to ATM operators who didn't do this who've lost hundreds or
even thousands of dollars before giving up on zeroconf.

My big worry with zeroconf is a service like Coinbase or Shapeshift
coming to rely on it, and then attempting to secure it by gaining
control of a majority of hashing power. 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 the 20%. There's
no way in a decentralized network to come to consensus about what
transactions are or are not valid without mining itself, so you could
end up in a situation where unless you're part of one of the big pools
you can't reliably mine at all because your blocks may get rejected for
containing doublespends.

One of my goal with standard replace-by-fee is to prevent this scenario
by forcing merchants and others to implement ways of accepting zeroconf
transactions safely that work in a decentr

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mike Hearn]

Hi Adam,

I am still confused about whether you actually support an increase in the
block size limit to happen right now. As you agree that this "layer 2" you
speak of doesn't exist yet, and won't within the next 10-12 months (do you
agree that actually?), can you please state clearly that you will support
Gavin's patch once posted? As Gavin's work takes some ideas from BIP100 but
does/soon will have some code associated with it.

But if we do no R&D on layer2, and insist that clients can never
> change to become layer2 aware, and layer2 is too hard etc
>

I think there's been some confusion here.

I, at least, have never argued that other systems can *never* happen. Never
is a long time, and I myself maintain a payment channels implementation.
These things have their place.

The argument is solely around the need to raise the block size *now* and
not allow the existing layer 1 to gum up and fall over.

If Stroem or Lightning or other block chains or Coinbase or secure hardware
tokens or whatever take off and people start moving bitcoins around that
way - fine. If they're choosing it of their own free will I have no issue
with that, nor does anyone else, I suspect.

However you don't seem fully confident that people actually will choose
whatever is being cooked up as "layer 2", if left to their own devices.
Indeed it's impossible for anyone to know that, as no "layer 2" actually
exists. Any such implementation could have all sorts of flaws that lead to
it not gaining traction.


> No offence but please find a way to gracefully stop and rejoin the
> constructive process. You can disagree on factors and points and be
> collaborative others disagree frequently and have done productive work
> cordially for years  under the BIP process.


As you know from the discussion with myself and Gavin a few days ago on
IRC, neither of us believe any such constructive process exists. There is
another thread to discuss the lack of such a process.


> - Did you accept payment from companies to lobby for 20MB blocks?


Oh please. Conspiracy theories, now, Adam? My position has been consistent
for years. I don't care whether the figure is 20 or something else (looks
like it'll be lucky 8 instead), but I have always been clear that the limit
must rise.

But for the avoidance of doubt: the answer is no.

Gavin is paid by MIT. The MIT deal gives Gavin complete independence.

I am currently self employed and most of income comes from a client that is
actually interested in Lighthouse. Luckily they have given me some leeway
to do general Bitcoin development as well, which this business falls under.
I would *much* rather be working on Lighthouse than this, and so would they.

But seeing as you've gone there - let me flip this around. Blockstream has
a very serious conflict of interest in this situation. I am by no means the
first to observe this. You are building two major products:

   1. Sidechains, a very complex approach to avoid changing the Bitcoin
   consensus rules to add new features.
   2. Lightning, a so-called "layer two" system for transaction routing

No surprise, the position of Blockstream employees is that hard forks must
never happen and that everyone's ordinary transactions should go via some
new network that doesn't yet exist.

The problem is that rather than letting the market decide between ordinary
Bitcoin and Lightning, you are attempting to strangle the regular Bitcoin
protocol because you don't trust people to spontaneously realise that they
should be using your companies products.

I know that many of you guys had these views before joining Blockstream. I
am not saying you are being paid to have views you didn't previously have.
I realise that birds of a feather flock together.

Regardless, that conflict of interest DOES exist, whether you like it or
not, because if you succeed in running Bitcoin out of capacity your own
company stands to benefit from selling consulting and services around your
preferred solutions.

With respect to user rights: all the polling done so far suggests users who
are paying attention strongly support increasing the block size. For
example:

Q: "Should the bitcoin block size be raised in the next two years"
A: 92% yes

http://www.poll-maker.com/results329839xee274Cb0-12#tab-2

Additionally, many Bitcoin users have explicitly delegated handling the
technical details to someone else, like a payment processor or their wallet
developers. Those people are nearly all sure that the block size limit
should rise too.

So please don't engage in idle speculation about "users vs companies". They
aren't some kind of opposing forces. Companies live for their users, and
many of those companies were formed by long time Bitcoin users.

And finally, the Bitcoin social contract is not defined by whatever random
state the code was in at the time Gavin decided to focus on research. Both
Gavin and I have been working on Bitcoin longer than you, Gregory or Peter
Todd. The social contract was and still

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

[Chun Wang]

Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

On Fri, Jun 19, 2015 at 9:33 PM, 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 they consider using FSS RBF instead?
>
> Best,
> Stephen
>
> On Fri, Jun 19, 2015 at 6: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 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 actu

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

[Gavin Andresen]

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
replace-by-fee before doing that, because until that happens replace-by-fee
just makes it easier to steal from bitcoin-accepting merchants.

I will tell you the same thing about 8MB blocks: until most merchants
support bigger blocks I will strongly encourage you keep creating
less-than-1MB blocks. If we want Bitcoin to succeed more quickly, we should
all be thinking about what is good for the whole system: users, merchants,
exchanges and miners.

As always, if you have questions or concerns feel free to email me.


-- 
--
Gavin Andresen
--
___
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

[Stephen Morse]

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 19, 2015 at 6: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 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
>

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Marcel Jamin]

> At the risk of stating cliches, the Mac came before the Windows PC…Yahoo!
came before Google…MySpace came before Facebook…

And TCP/IP came before... oh wait...

2015-06-19 14:02 GMT+02:00 Eric Lombrozo :

>
> On Jun 19, 2015, at 3:45 AM, Dr Adam Back  wrote:
>
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon.  They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.
>
>
> Exactly, Adam.
>
> Except, I think the genie is out of the bottle - these ideas are too
> powerful for them to be killed forever. They will probably survive even if
> this scenario comes to pass…but in a different network under a different
> name…and Bitcoin will be relegated to the history books and walls of
> museums.
>
> Most of the potential brainpower available on this Earth to make serious,
> profound contributions to this movement haven’t even begun to touch it.
> Just because you happen to run a Bitcoin startup right now…even if you’ve
> received millions of dollars in funding…don’t think that the whole world
> has low standards and is lazy! Someone WILL eventually build something
> better than we can presently imagine.
>
> First mover advantage and the network effect are vastly overrated. At the
> risk of stating cliches, the Mac came before the Windows PC…Yahoo! came
> before Google…MySpace came before Facebook…Bitcoin came before  know yet>.
>
>
> - 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

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

IPv4 came before IPv6…you pick up on things quickly :)

> On Jun 19, 2015, at 5:48 AM, Marcel Jamin  wrote:
> 
> > At the risk of stating cliches, the Mac came before the Windows PC…Yahoo! 
> > came before Google…MySpace came before Facebook…
> 
> And TCP/IP came before... oh wait...
> 
> 2015-06-19 14:02 GMT+02:00 Eric Lombrozo  >:
> 
>> On Jun 19, 2015, at 3:45 AM, Dr Adam Back > > wrote:
>> 
>> That wont be good for the companies either, but they may not see that
>> until they've killed it, many companies operate on a1 or 2 year
>> time-horizon.  They may say screw layer2, I have a runway and I need
>> micropayments to the wazoo and I dont have the dev resources for that.
> 
> Exactly, Adam.
> 
> Except, I think the genie is out of the bottle - these ideas are too powerful 
> for them to be killed forever. They will probably survive even if this 
> scenario comes to pass…but in a different network under a different name…and 
> Bitcoin will be relegated to the history books and walls of museums.
> 
> Most of the potential brainpower available on this Earth to make serious, 
> profound contributions to this movement haven’t even begun to touch it. Just 
> because you happen to run a Bitcoin startup right now…even if you’ve received 
> millions of dollars in funding…don’t think that the whole world has low 
> standards and is lazy! Someone WILL eventually build something better than we 
> can presently imagine.
> 
> First mover advantage and the network effect are vastly overrated. At the 
> risk of stating cliches, the Mac came before the Windows PC…Yahoo! came 
> before Google…MySpace came before Facebook…Bitcoin came before  yet>.
> 
> 
> - Eric Lombrozo
> 
> --
> 
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net 
> 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development 
> 
> 
> 



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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[GC]

>When is the right time to allow space pressure to rise that ratio?
>When the subsidy is at 1.5625, for example, it may be too late to

I don¹t believe we have to decide, the miners will do that and are doing
that already.

>start a non-catastrophic transition from subsidies to fees.
>I don't claim to know that, but it's something that worries me.
>No matter how many people say "that's too far away in the future to
>worry about it", I still worry about it and I'm sure more people do.
>What if "when it's time to care about it" we discover that we should
>have started to do things about it long ago to minimize the risks of
>this transition?

Hmmm. What should be the price of an email? How much should DARPA have
charged for using TCP/IP?

I see a lot of well-paid, first-world technologists arguing for commercial
returns on a nacent protocol which could could offer benefits to the
unbanked.
Is that really the vision: to (re)build a de-centralized Paypal with
slightly cheaper fees and cool hooks into off-chain commercial systems
providing profits for the already rich?

>--
>
>___
>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] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Brooks Boyd]

On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn  wrote:

> Or alternatively, fix the reasons why users would have negative
>> experiences with full blocks
>>
>
> It's impossible, Mark. *By definition* if Bitcoin does not have
> sufficient capacity for everyone's transactions, some users who were using
> it will be kicked out to make way for the others. Whether that happens in
> some kind of stable organised way or (as with the current code) a fairly
> chaotic way doesn't change the fundamental truth: *some users will find
> their bitcoin savings have become uneconomic to spend*.
>
> Here's a recent user complaint that provides a preview of coming
> attractions:
>
>
> https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
>
> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
>> onto a paper wallet. When I try to send it, a window pops up stating
>> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
>
>
>
Has there been any talk about reducing the time between blocks? If blocks
were allowed to come twice as fast, they would be able to clear pending
transactions in the mempool the same as if the block size doubled, but
would allow mining to stay more decentralized since miners wouldn't be
working on such large-scale blocks? It would still take more storage space
to store the blockchain, though.

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

[Bitcoin-development] Fee Market Effects

[Tim Witters]

A lot of standpoints for keeping the current block size are focused on 
creating a healthy fee market. I have some open questions for this list 
in regards to the user incentives of using bitcoin, when such a strong 
fee market is in place.
In my scenario the average fee for a normal transactions will be around 
1$ to put in on the blockchain with a reasonable confirmation time.

1. How will we get user adoptions if the fees on bitcoin transactions 
our not competitive with other services like PayPal and the like. (from 
a payment solution viewpoint) It is one of the main ‘pitch lines’ to get 
people to adopt bitcoin. “Send value to the other side of the world for 
almost 0 fees”

2. Many suggest the use of a level 2 layer will facilitate the 
scalability for bitcoin with technologies like the lightning network. 
But to my knowledge, all these solutions still need to publish to the 
actual blockchain when they need to settle. Meaning you will have to pay 
the fees at least once. In case of lightning this will be when the 
channel is closed. 

This means moves more to a monthly payed service, where you open a 
payment channel each month and pay the fee at the end. But a system like 
this keeps money locked for the duration of the channel. And one of the 
main ‘pitch’ point of the bitcoin economy was you get your money 
instantly, not at the end of the month when the payment channel is 
closed. 

3. The idea of the fee market is people will start using the layer 2 
systems. When this happens, what are the incentives to keep running a 
node? The incentives today are already quite small, the only real one is 
to support the network or make payments through your own trusted node. 
If you are only using a layer 2 solution, are there any reasons left to 
run my own bitcoin node, resulting in less decentralization.

4. Do we need a fee market right now? It seems to me the current 
block reward is still high enough for miners to be able to make money 
and secure the network. No real fee market is therefore needed to help 
these miners. 

Regardless of our opinion, why don’t we let the miners decide? The 
BIP100 proposal seems to do this. If the majority of miners decide they 
want bigger blocks they just vote for this. If they want a fee market 
because their return is enough, they can keep the limit and let the 
demand for more blockspace result in a higher fee market. 
Just some of my thoughts about the results of full blocks and the 
resulting fee market. It seems to me a strong fee market might hurt the 
young ecosystem more, then it might help it (miners are currently 
compensated enough). The same goes for decentralization, when people 
more their resources to the level 2 solution or stop using bitcoin due 
to the higher fees compared to comparable services.
Cheers,
Tim Witters 
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back  wrote:
> 
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon.  They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.

Exactly, Adam.

Except, I think the genie is out of the bottle - these ideas are too powerful 
for them to be killed forever. They will probably survive even if this scenario 
comes to pass…but in a different network under a different name…and Bitcoin 
will be relegated to the history books and walls of museums.

Most of the potential brainpower available on this Earth to make serious, 
profound contributions to this movement haven’t even begun to touch it. Just 
because you happen to run a Bitcoin startup right now…even if you’ve received 
millions of dollars in funding…don’t think that the whole world has low 
standards and is lazy! Someone WILL eventually build something better than we 
can presently imagine.

First mover advantage and the network effect are vastly overrated. At the risk 
of stating cliches, the Mac came before the Windows PC…Yahoo! came before 
Google…MySpace came before Facebook…Bitcoin came before .


- 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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 3:45 AM, Dr Adam Back  > wrote:
> 
> That wont be good for the companies either, but they may not see that
> until they've killed it, many companies operate on a1 or 2 year
> time-horizon.  They may say screw layer2, I have a runway and I need
> micropayments to the wazoo and I dont have the dev resources for that.

Exactly, Adam.

Except, I think the genie is out of the bottle - these ideas are too powerful 
for them to be killed forever. They will probably survive even if this scenario 
comes to pass…but in a different network under a different name…and Bitcoin 
will be relegated to the history books and walls of museums.

Most of the potential brainpower available on this Earth to make serious, 
profound contributions to this movement haven’t even begun to touch it. Just 
because you happen to run a Bitcoin startup right now…even if you’ve received 
millions of dollars in funding…don’t think that the whole world has low 
standards and is lazy! Someone WILL eventually build something better than we 
can presently imagine.

First mover advantage and the network effect are vastly overrated. At the risk 
of stating cliches, the Mac came before the Windows PC…Yahoo! came before 
Google…MySpace came before Facebook…Bitcoin came before .


- 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] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Bryan Bishop]

On Fri, Jun 19, 2015 at 5:45 AM, Dr Adam Back  wrote:

> payment protocol layer in my view.  (If thats not obvious to some
> lurkers I elaborate on that argument  amongst other things here:
> https://www.youtube.com/watch?v=3dAdI3Gzodo )
>

Someone might find it more convenient to consume that in the form of text
instead:
http://diyhpl.us/wiki/transcripts/bitcoin-adam3us-fungibility-privacy/

- Bryan
http://heybryan.org/
1 512 203 0507
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Jorge Timón]

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn  wrote:
>> Or alternatively, fix the reasons why users would have negative
>> experiences with full blocks
>
>
> It's impossible, Mark. By definition if Bitcoin does not have sufficient
> capacity for everyone's transactions, some users who were using it will be
> kicked out to make way for the others. Whether that happens in some kind of
> stable organised way or (as with the current code) a fairly chaotic way
> doesn't change the fundamental truth: some users will find their bitcoin
> savings have become uneconomic to spend.

He doesn't mean that: he means solving the mempool and crashes and
hitting the limit would have.
If the chain has limited size it is a scarce resource and people have
to bid for it: nothing unexpected or wrong about that.
Of course, people that believe the limit should be completely removed
eventually because they don't care about mining being decentralized
(or fail to see the relation between the two) may have a very
different view about this.

On Fri, Jun 19, 2015 at 12:08 PM, GC  wrote:
> Timeframe for transaction fees topping block reward fees => many years in
> the future, based on current ratio of block reward to fees.

Do you think that this ratio is unrelated to an abundant (non-scarce)
block size?
When is the right time to allow space pressure to rise that ratio?
When the subsidy is at 1.5625, for example, it may be too late to
start a non-catastrophic transition from subsidies to fees.
I don't claim to know that, but it's something that worries me.
No matter how many people say "that's too far away in the future to
worry about it", I still worry about it and I'm sure more people do.
What if "when it's time to care about it" we discover that we should
have started to do things about it long ago to minimize the risks of
this transition?

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

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Eric Lombrozo]

> On Jun 19, 2015, at 2:37 AM, Mike Hearn  wrote:
> 
> Or alternatively, fix the reasons why users would have negative experiences 
> with full blocks
> 
> It's impossible, Mark. By definition if Bitcoin does not have sufficient 
> capacity for everyone's transactions, some users who were using it will be 
> kicked out to make way for the others. Whether that happens in some kind of 
> stable organised way or (as with the current code) a fairly chaotic way 
> doesn't change the fundamental truth: some users will find their bitcoin 
> savings have become uneconomic to spend.
> 
> Here's a recent user complaint that provides a preview of coming attractions:
> 
> https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
>  
> 
> 
> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) 
> onto a paper wallet. When I try to send it, a window pops up stating 
> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389 
> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
> 
> These sorts of complaints will get more frequent and more extreme in the 
> coming months. I realise that nobody at Blockstream is  in the position of 
> running an end user facing service, but many of us are  and we will be 
> the ones that face the full anger of ordinary users as Bitcoin hits the wall.

Mike,

With all due respect, many of us DO run end user facing services…and would 
rather see a fundamental problem *fixed* rather than merely covered up 
temporarily…hoping nobody notices.

The user experience of Bitcoin is already horrendous…unless you use a 
centralized validator web wallet. Even SPV is fundamentally broken (and I would 
have pegged you for being one of the people most directly aware of this fact). 
If we’re going for centralized validation, why even use a blockchain in the 
first place? We already have much faster, more efficient technology that can do 
that kind of stuff at a fraction of the cost. If you have well-established 
entities running banking services, we have other mechanisms in place that can 
help keep them honest…other far more efficient protocols. We’re basically 
defeating the very purpose of this invention.

Then there are a bunch of other “inconveniences” about the way Bitcoin 
currently works. For instance, have you ever received a bunch of small payments 
(i.e. a crowdsale) and then found yourself in the position of having to 
suddenly move a big chunk of that on the blockchain…only to discover all the 
txouts you were spending added up to hundreds of kB or more? Or have you ever 
had to send a small payment but only had one large output in your wallet…which 
meant that the entirety of those funds were tied up until the first transaction 
got signed and propagated? Yes, the protocol has MANY serious issues…of which 
the “send and forget” fee model as opposed to the “send and bid model” is just 
one.

Bitcoin was designed from the beginning with the idea that sooner or later fees 
would be a significant component of the network. The problem was never really 
fully addressed and solved - I’m glad to see that finally some good people in 
this space are starting to seriously think about solutions.

Mike, are you telling us you’d rather avoid user complaints at all costs even 
if that means building something shitty for them that doesn’t really serve its 
stated purpose? If those are your standards then no thanks, I don’t want to be 
part of your fork. And I don’t think I’m alone in this sentiment.


- Eric Lombrozo


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




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] Mailman incompatibility with DKIM ...

[Mike Hearn]

>
> Mailman isn't resigning it.  Should it be?  Does other mailing list
> software?
>

Mailman must take responsibility for the mail itself. It doesn't have to
actually sign with DKIM to do so: for backwards compatibility, spam filters
fall back to other heuristics to try and figure out the 'owner' of the mail
if it doesn't use DKIM. Those heuristics can go wrong of course. Ideally
all mail would be DKIM signed. There's no reason not to do it, really.

Yes mailing lists that edit people's emails resign. For example, from a
recent message to the bitcoinj list

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
*d=googlegroups.com *; s=20120806;
h=to:from:subject:date:lines:message-id:references:mime-version
 :content-type:user-agent:in-reply-to:x-original-sender
 :x-original-authentication-results:reply-to:precedence:mailing-list
 :list-id:list-post:list-help:list-archive:sender:list-subscribe
 :list-unsubscribe;



> I suppose it is somewhat acceptable for us to remove subject tags and
> footers if we have no choice...
>

Good email clients can extract the same information from the headers
anyway. I filter all my mail based on them, and the headers also contain
unsubscribe instructions. Gmail is capable of using them programmatically.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Dr Adam Back]

A lot of people think a layer2 is needed, that has a higher
(algorithmic) scale in use of layer1 block-space but preserves
functionality and uplifts security from layer1.  An example would be
lightning or similar.

But there are many things that could be done.  Pure offchain is a weak
form of layer2.  Its running today and maybe its handling 90-99% range
of all transactions right now (mostly in exchanges for example).  This
layer can be incrementally hardened.  It can also have standardised
APIs across vendors of custodians, and opt-in support of those APIs in
wallets.  This would provide a convenience choice.  Greenaddress also
for low-mid assurances solves the unconfirmed transactions. It's
probably not reasonable to expect bitcoin directly solve fast
unconfirmed transactions.   Probably intermediate configurations in
complexity somewhere between greenaddress (2 of 2 + timelocked 1 sig)
and lightning may exist also.  The internet doesnt stop at layer1.

(Which would then leave people who are uninterested in changing client
software to handle layer2, as "layer1 will always be enough die-hards"
(in the refusing the future and facing the O(n^2) scaling wall or
centralisation death with perplexing optimism :)  Ok, not so
constructive but maybe a gentle reminder that it is not constructive
in the reverse direction either to throw around often false
characterisations.  We're here now to improve bitcoin so lets do that.

What I said here seemed like it maybe subject to misinterpretation so
to clarify:

On 19 June 2015 at 11:22, Dr Adam Back  wrote:
> For example it could hypothetically allow 10MB blocks on
> one chain and 100kB blocks on the main chain.  People say complexity,
> scary.  Sure I am talking longer term, but we have to also make
> concrete forward progress to the future or we'll be stuck here talking
> about perilously large constant changes in 5 years time!

I should clarify that I meant there I was assuming we do one increase
within the next 12 months frame that gives buffer for 5 years r&d to
improve things and build layer2.

But if we do no R&D on layer2, and insist that clients can never
change to become layer2 aware, and layer2 is too hard etc then our
risk would be we'd be back in the discussion of kicking the can afresh
again in some years with some even more centralising size change.

Sure we should make the transition and introduction to layer2 and an
intermediate crunch smoother, but "20MB now or else" isn't really
helping.  It did help get the conversation revived, but at this point
its a hindrance.  Seriously a big hindrance.  No offence but please
find a way to gracefully stop and rejoin the constructive process.
You can disagree on factors and points and be collaborative others
disagree frequently and have done productive work cordially for years
under the BIP process.


About scaling again:

Here is what I said before in my TL;DR post about my thoughts on how
we would start on throughput short-term to have space to do layer2
development.

> I think almost everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already.  All of those 3 things are being
> actively worked on right now, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.


Btw I wonder if Gavin or Mike would be willing to answer another
question I forgot from my TL;DR post which was:

- Did you accept payment from companies to lobby for 20MB blocks?  Do
you consider that something appropriate to publicly disclose if so?
Do you consider that user rights should come above or below company
interests in Bitcoin?


FWIW on pondering that last question "should user rights come above or
below company interests" I think my view of the guiding principle is
starkly clear to me: that user rights should be the primary thing to
optimise for.  Businesses are providing service to users, their
interests are secondary in so far as if they are enabled to provide
better service thats good.

Bitcoin is a user p2p currency, with a social contract and a strong
user ethos.  Importing and forcing company interests would likely be
the start of a slippery slope towards an end to Bitcoin.   If we allow
business rights to be paramount it seems likely that we will end back
at the status quo as bitcoin payment processors grow, conglomerate and
become paypal/bank like or actual banks and then their interests and
exposures are the same as the banks and they'll want to import their
business models

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

[Peter Todd]

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 miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.

Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil atta

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

[Warren Togami Jr.]

On Fri, Jun 19, 2015 at 12:24 AM, Mike Hearn  wrote:

> The new list currently has footers removed during testing.  I am not
>> pleased with the need to remove the subject tag and footer to be more
>> compatible with DKIM users.
>>
>
> Lists can do what are effectively MITM attacks on people's messages in any
> way they like, if they resign for the messages themselves. That seems fair
> to me!  :)
>

Mailman isn't resigning it.  Should it be?  Does other mailing list
software?


>
>
>>  I'm guessing DKIM enforcement is not very common because of issues like
>> this?
>>
>
> DKIM is used by most mail on the internet. DMARC rules that publish in DNS
> statements like "All mail from bitpay.com is signed correctly so trash
> any that isn't" are used on some of the worlds most heavily phished domains
> like google.com, PayPal, eBay, and indeed BitPay.
>
> These rules are understood and enforced by all major webmail providers
> including Gmail. It's actually only rusty geek infrastructure that has
> problems with this, I've never heard of DKIM/DMARC users having issues
> outside of dealing with mailman. The vast majority of email users who never
> post to technical mailing lists benefit from it significantly.
>
> Really everyone should use them. Adding cryptographic integrity to email
> is hardly a crazy idea :)
>

I understand the reason to protect the "heavily phished" domains.  I heard
that LKML does not modify the subject or add a footer, perhaps because it
would make it incompatible with DKIM of the several big corporate domains
who participate.

I suppose it is somewhat acceptable for us to remove subject tags and
footers if we have no choice...

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

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

[Mike Hearn]

>
> The new list currently has footers removed during testing.  I am not
> pleased with the need to remove the subject tag and footer to be more
> compatible with DKIM users.
>

Lists can do what are effectively MITM attacks on people's messages in any
way they like, if they resign for the messages themselves. That seems fair
to me!  :)


>  I'm guessing DKIM enforcement is not very common because of issues like
> this?
>

DKIM is used by most mail on the internet. DMARC rules that publish in DNS
statements like "All mail from bitpay.com is signed correctly so trash any
that isn't" are used on some of the worlds most heavily phished domains
like google.com, PayPal, eBay, and indeed BitPay.

These rules are understood and enforced by all major webmail providers
including Gmail. It's actually only rusty geek infrastructure that has
problems with this, I've never heard of DKIM/DMARC users having issues
outside of dealing with mailman. The vast majority of email users who never
post to technical mailing lists benefit from it significantly.

Really everyone should use them. Adding cryptographic integrity to email is
hardly a crazy idea :)


> It seems that Sourceforge silently drops DKIM enforced mail like jgarzik's.
>

It's not SourceForge, it's your spam filter. His mail gets through to me
but it's all in the spam folder.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mike Hearn]

>
> Yeah, but increasing block-size is not a longterm solution.


Are you sure? That sort of statement is hard to answer because it doesn't
say what you think long term is, or how much you expect Bitcoin to grow.

Satoshi thought it was a perfectly fine long term solution because he
thought hardware would get cheaper as fast or faster than Bitcoin would
grow. You may disagree with him, but as we're talking about the future are
you 100% certain he was wrong? I did calculations a long time ago that
suggested even with today's hardware (+some software optimisations) it
would be feasible to keep up with Visa.

Hardware improvements can be unintuitive. There's a spreadsheet here that
lets you play with various parameters.

https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128

(note: the spreadsheet says avg txn size is 250 bytes, but if you check the
formula for the middle column, it does actually use 500 bytes as the
multiplier hard coded).


> Necessary higher fees are a logical consequence of lower subsidies.
> Bitcoin was basically free to use at the beginning because miners got paid
> with new coins at  the expense of those who already hold coins.
> Eventually there needs to be a mechanism which matches supply and demand.
>

That's not clear either, I'm afraid.

Remember that there's an upper limit on how high Bitcoin fees can go. When
fees become higher than what the banking system charges, many users won't
use Bitcoin for moving money around anymore. Fees cannot really go much
higher than that even if you assume the currency is still attractive for
other reasons, because people would just sell their coins for fiat, move
the fiat, and buy back the coins the other side.

The way mining will be funded in future is an open question. There are
differing proposals. Still, even with a higher hard block size limit,
miners can always refuse to mine transactions that don't include a
particular fee. So if you're worried about this, miners aren't being forced
into any particular policy.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[Warren Togami Jr.]

On Thu, Jun 18, 2015 at 11:56 PM, Mike Hearn  wrote:

> We already removed the footer because it was incompatible with DKIM
>> signing.  Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
>> with DKIM header signing only if the poster manually prepends it in their
>> subject header.
>>
>
> I still see footers being added to this list by SourceForge?
>

The new list currently has footers removed during testing.  I am not
pleased with the need to remove the subject tag and footer to be more
compatible with DKIM users.


>
>
>> Opinions?
>>
>
> I've asked Jeff to not use his @bitpay.com account for now.
>
>
I'm guessing DKIM enforcement is not very common because of issues like
this?

It seems that Sourceforge silently drops DKIM enforced mail like
jgarzik's.  LF seems to pass along their mail but mangles the header/body
and makes DKIM verification fail, which causes gmail to toss it into the
spam folder.  I think this behavior is slightly worse than Sourceforge
because it makes the poster think their message was successfully sent (it
is in the archive), but many subscribers never see it due to the spam
binning.

I don't see any good solution to this except an auto-reject for DKIM
enforced domain postings.  Yes this is rather terrible, but the instant
rejection is vastly better than Sourceforge silently dropping the post or
LF getting stuck in spam filters.

We should also auto-reject any other reason for mail getting stuck in the
moderation queue like including non-subscribers.  I considered
auto-rejecting spam too, but that could go horribly wrong as a false From
address could make the Mailman server into a spammer itself.  We may have
no choice but to silently drop spam for that reason.

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

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[GC]

Benjamin,

Timeframe for network congestion and users experiencing service
degradation => between now and middle of next year.

Timeframe for transaction fees topping block reward fees => many years in
the future, based on current ratio of block reward to fees.

What is the more pressing requirement now? A working ³fee market² or a
reliable, useful payment network that scales without falling over in the
next 2-3 years.

On 19/6/15 4:53 pm, "Benjamin"  wrote:

>Yeah, but increasing block-size is not a longterm solution. Necessary
>higher fees are a logical consequence of lower subsidies. Bitcoin was
>basically free to use at the beginning because miners got paid with
>new coins at  the expense of those who already hold coins. Eventually
>there needs to be a mechanism which matches supply and demand.
>
>On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn  wrote:
>>> Or alternatively, fix the reasons why users would have negative
>>> experiences with full blocks
>>
>>
>> It's impossible, Mark. By definition if Bitcoin does not have sufficient
>> capacity for everyone's transactions, some users who were using it will
>>be
>> kicked out to make way for the others. Whether that happens in some
>>kind of
>> stable organised way or (as with the current code) a fairly chaotic way
>> doesn't change the fundamental truth: some users will find their bitcoin
>> savings have become uneconomic to spend.
>>
>> Here's a recent user complaint that provides a preview of coming
>> attractions:
>>
>> 
>>https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to
>>_pay_over_10_network_fee/
>>
>>> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159
>>>bits)
>>> onto a paper wallet. When I try to send it, a window pops up stating
>>> "insufficient funds for bitcoin network fee, reduce payment amount by
>>>1,389
>>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with
>>>$2.50.
>>
>>
>> These sorts of complaints will get more frequent and more extreme in the
>> coming months. I realise that nobody at Blockstream is  in the position
>>of
>> running an end user facing service, but many of us are  and we will
>>be
>> the ones that face the full anger of ordinary users as Bitcoin hits the
>> wall.
>>
>> 
>>-
>>-
>>
>> ___
>> 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

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

[Mike Hearn]

>
> We already removed the footer because it was incompatible with DKIM
> signing.  Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
> with DKIM header signing only if the poster manually prepends it in their
> subject header.
>

I still see footers being added to this list by SourceForge?


> Opinions?
>

I've asked Jeff to not use his @bitpay.com account for now.

The only real fix is to use a mailing list operator that is designed to
operate correctly with DKIM/DMARC, either by not modifying messages in
transit, or by re-sending (and ideally re-signing) under their own identity.

Though I'm sure this won't be an issue for the Linux Foundation, the latter
approach is dangerous because it means the list operator takes full
responsibility for any spamming that occurs from that domain. If the mail
server is ever hacked or spammers start posting to the lists themselves,
all that spam will be seen as originating from the listserv itself and the
reputation will be degraded. It can end with everyone's mail going to the
spam folder.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Benjamin]

Yeah, but increasing block-size is not a longterm solution. Necessary
higher fees are a logical consequence of lower subsidies. Bitcoin was
basically free to use at the beginning because miners got paid with
new coins at  the expense of those who already hold coins. Eventually
there needs to be a mechanism which matches supply and demand.

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn  wrote:
>> Or alternatively, fix the reasons why users would have negative
>> experiences with full blocks
>
>
> It's impossible, Mark. By definition if Bitcoin does not have sufficient
> capacity for everyone's transactions, some users who were using it will be
> kicked out to make way for the others. Whether that happens in some kind of
> stable organised way or (as with the current code) a fairly chaotic way
> doesn't change the fundamental truth: some users will find their bitcoin
> savings have become uneconomic to spend.
>
> Here's a recent user complaint that provides a preview of coming
> attractions:
>
> https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
>
>> Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
>> onto a paper wallet. When I try to send it, a window pops up stating
>> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
>> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
>
>
> These sorts of complaints will get more frequent and more extreme in the
> coming months. I realise that nobody at Blockstream is  in the position of
> running an end user facing service, but many of us are  and we will be
> the ones that face the full anger of ordinary users as Bitcoin hits the
> wall.
>
> --
>
> ___
> 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] Mailman incompatibility with DKIM ...

[Warren Togami Jr.]

Both you and jgarzik experienced mail getting tossed into gmail's spam
folder thanks to DKIM... I am concerned that DKIM is too fragile and not
very compatible with mailing lists.

We already removed the footer because it was incompatible with DKIM
signing.  Keeping the "[Bitcoin-dev] " prepend tag in subject is compatible
with DKIM header signing only if the poster manually prepends it in their
subject header.

I am already concerned that the lack of the Mailman footer will make it
hard to identify where exactly subscribers need to go to unsubscribe or
look at archives.  Removing the subject tag might make DKIM enforcement
work a lot better, but I can easily see our obtuse subscribers as being
extra confused by this.

Opinions?

Warren

On Thu, Jun 18, 2015 at 11:38 PM, Arthur  wrote:

> warren | bad_duck: try manually adding "[Bitcoin-dev] " to the beginning
> of the subject
>
> --
> Arthur
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Mike Hearn]

>
> Or alternatively, fix the reasons why users would have negative
> experiences with full blocks
>

It's impossible, Mark. *By definition* if Bitcoin does not have sufficient
capacity for everyone's transactions, some users who were using it will be
kicked out to make way for the others. Whether that happens in some kind of
stable organised way or (as with the current code) a fairly chaotic way
doesn't change the fundamental truth: *some users will find their bitcoin
savings have become uneconomic to spend*.

Here's a recent user complaint that provides a preview of coming
attractions:

https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/

Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
> onto a paper wallet. When I try to send it, a window pops up stating
> "insufficient funds for bitcoin network fee, reduce payment amount by 1,389
> bits?" This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.


These sorts of complaints will get more frequent and more extreme in the
coming months. I realise that nobody at Blockstream is  in the position of
running an end user facing service, but many of us are  and we will be
the ones that face the full anger of ordinary users as Bitcoin hits the
wall.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

[Dr Adam Back]

Nicely put Eric.  Relatedly my initial experience with Bitcoin in
trying to improve bitcoin in fungibility, privacy & decentralisation,
I found some interesting things, like Confidential Transactions (that
Greg Maxwell has now optimised via a new generalisation of the
hash-ring signature construct he invented and with Pieter made part of
the alpha side-chain release) and a few other things.

As I went then to discuss and learn: a) what are the characteristics
needed for inclusion (clearly things need to fit in with how things
work, not demand massive rewrites to accommodate and to not conflict
with existing important design considerations), so that I could make
proposals in a practically deployable way, and then b) the
practicality of getting a proposed change that say people found
clearly useful.  Then I bumped into the realisation that this is
actually really high risk to change, and consensus critical coding
security is very complex and there are some billion $ resting on
getting this rigidly correct under live conditions, so that deployment
must be cautious and incremental and rigorously tested.

So then I focussed instead on question of whether we could improve
bitcoins development model: how could we allow bitcoin to more rapidly
and agilely test beta features or try novel things to see how they
would work (as someone might do in a feature branch of a normal FOSS
project, to code and test a proposal for later addition), but with
criteria we want real bticoins so there is economic incentive as that
is actually part of the bitcoin protocol so you've not validated
something unless you're run it in a real network with money.  I was
hypothesising therefore we need a way to run bitcoin beta network.
There's a thread about this here stretching back to may 2013.

Or similarly to run in parallel kind of subnets with different
trade-offs or features that are not easy to merge or high risk to
apply all at once to bitcoin with the inflight billions in capital and
transactions on it.

Anyway I thought that was a productive line of thinking, and generally
people seemed to agree and problem statement of 2wp: then 1wp
mechanism was proposed and then Greg extracted a concept from his
SNARK witness idea (which encapsulates a snark variant of a 2wp) but
now without snarks, then 2wp a conservative crypto 2wp proposal was
made.  This was dec 2013 I think on wizards channel.  The sidechain
alpha release now makes this a (alpha quality and so testnet coin, and
without DMMS peg) reality.  I could imagine others who have a desire
to try things could elect to do so and copy that patch-set and make
more side-chains.

This is inherently non-coercive because you largely do not directly
change bitcoin by doing this, people elect to use which ever chain
suits them best given their usecase.  If the sidechain is really early
stage it should have test-net coins in it not bitcoins in it, but
still its caveat emptor kind of beta chain, with good testing but
non-trivial to soft-fork on bitcoin but managable refactor a sidechain
to integrate something novel or try some existing feature (like the
segregated witness which robustly addresses malleability for example)

So I dont want to say side-chains are some magical solution to
everything, but its a direction that others may like to consider for
how to test or even run alternative trade-offs bitcoin side-chains in
parallel.  For example it could hypothetically allow 10MB blocks on
one chain and 100kB blocks on the main chain.  People say complexity,
scary.  Sure I am talking longer term, but we have to also make
concrete forward progress to the future or we'll be stuck here talking
about perilously large constant changes in 5 years time!

This approach also avoids the one-size fits all problem.

Extension-blocks are an in-chain sub-net type of thing that has a
security boost by being soft-fork enforced (relative to side-chains
which are looser coupled and so more flexible relative to the simplest
form of extension-blocks)

Adam

On 19 June 2015 at 07:59, Eric Lombrozo  wrote:
> I don’t think the issue is between larger blocks on the one hand and things
> like lightning on the other - these two ideas are quite orthogonal.
>
> Larger blocks aren’t really about addressing basic scalability concerns -
> for that we’ll clearly need architectural and algorithmic improvements…and
> will likely need to move to a model where it isn’t necessary for everyone to
> validate everyone else’s latte purchases. Larger blocks might, at best, keep
> the current system chugging along temporarily - although I’m not sure that’s
> necessarily such a great thing…we need to create a fee market sooner or
> later, and until we do this, block size issues will continue to crop up
> again and again and economic incentives will continue to be misplaced. It
> would be nice to have more time to really develop a good infrastructure for
> this…but without real market pressures, I’m not sure it will happen at all.
> Necessit