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

[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

[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] User vote in blocksize through fees

[Chun Wang]

To tell you the truth. It is only because most miners are not located
in the West. If Slush, Eligius and BTC Guild still on top 3, the core
developers, including brain-dead Mike Hearn, would be very happy to do
BIP100 just like they did BIP34 and BIP66. Shame on you!

On Sun, Jun 14, 2015 at 6:20 AM, Danny Thorpe  wrote:
> Please forgive my ignorance, but why should Bitcoin users have a say in
> block size limits?  It's the miners and Bitcoin node operators that bear the
> burden of managing large blocks, no?
>
> Users voting on network parameters sounds like neighbors voting on how deep
> my swimming pool should be.
>
> Thanks,
> -Danny
>
> On Fri, Jun 12, 2015 at 11:11 AM, Peter Todd  wrote:
>>
>> Jeff Garzik recently proposed that the upper blocksize limit be removed
>> entirely, with a "soft" limit being enforced via miner vote, recorded by
>> hashing power.
>>
>> This mechanism within the protocol for users to have any influence over
>> the miner vote. We can add that back by providing a way for transactions
>> themselves to set a flag determining whether or not they can be included
>> in a block casting a specific vote.
>>
>> We can simplify Garzik's vote to say that one of the nVersion bits
>> either votes for the blocksize to be increased, or decreased, by some
>> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
>> nVersion bit in transactions themselves, also voting for an increase or
>> decrease. Transactions may only be included in blocks with an
>> indentical vote, thus providing miners with a monetary incentive via
>> fees to vote according to user wishes.
>>
>> Of course, to cast a "don't care" vote we can either define an
>> additional bit, or sign the transaction with both versions. Equally we
>> can even have different versions with different fees, broadcast via a
>> mechanism such as replace-by-fee.
>>
>>
>> See also John Dillon's proposal for proof-of-stake blocksize voting:
>>
>>
>> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>>
>>
>> --
>>
>> ___
>> 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] Fwd: Block Size Increase Requirements

[Chun Wang]

The current max block size of 100 bytes is not power of two anyway.

On Mon, Jun 1, 2015 at 10:46 PM, Oliver Egginger  wrote:
> On Mon, Jun 1, 2015 at 3:59 PM, Gavin Andresen wrote:
>> What do other people think?  Would starting at a max of 8 or 4 get
>> consensus?  Scaling up a little less than Nielsen's Law of Internet
>> Bandwidth predicts for the next 20 years?  (I think predictability is
>> REALLY important).
>>
>> I chose 20 because all of my testing shows it to be safe, and all of my
>> back-of-the-envelope calculations indicate the costs are reasonable.
>>
>> If consensus is "8 because more than order-of-magnitude increases are
>> scary" -- ok.
>
> It would feel better for me if you would keep the power of two:
>
> 2^0 = 1MB
> 2^1 = 2MB
> 2^2 = 4MB
> 2^3 = 8MB
> .
> .
> .
>
> But that's only personal. Maybe other people feeling the same.
>
> - oliver
>
> --
> ___
> 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] Fwd: Block Size Increase Requirements

[Chun Wang]

That is good. I oppose 20MB because I estimate it may increase the
overall orphan rate to an unacceptable level. 5MB, 8MB or probably
10MB should be ok.

On Mon, Jun 1, 2015 at 9:59 PM, Gavin Andresen  wrote:
> On Mon, Jun 1, 2015 at 7:20 AM, Chun Wang <1240...@gmail.com> wrote:
>>
>> I cannot believe why Gavin (who seems to have difficulty to spell my
>> name correctly.) insists on his 20MB proposal regardless the
>> community. BIP66 has been introduced for a long time and no one knows
>> when the 95% goal can be met. This change to the block max size must
>> take one year or more to be adopted. We should increase the limit and
>> increase it now. 20MB is simply too big and too risky, sometimes we
>> need compromise and push things forward. I agree with any solution
>> lower than 10MB in its first two years.
>>
>
> Thanks, that's useful!
>
> What do other people think?  Would starting at a max of 8 or 4 get
> consensus?  Scaling up a little less than Nielsen's Law of Internet
> Bandwidth predicts for the next 20 years?  (I think predictability is REALLY
> important).
>
> I chose 20 because all of my testing shows it to be safe, and all of my
> back-of-the-envelope calculations indicate the costs are reasonable.
>
> If consensus is "8 because more than order-of-magnitude increases are scary"
> -- ok.
>
> --
> --
> Gavin Andresen

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

I cannot believe why Gavin (who seems to have difficulty to spell my
name correctly.) insists on his 20MB proposal regardless the
community. BIP66 has been introduced for a long time and no one knows
when the 95% goal can be met. This change to the block max size must
take one year or more to be adopted. We should increase the limit and
increase it now. 20MB is simply too big and too risky, sometimes we
need compromise and push things forward. I agree with any solution
lower than 10MB in its first two years.

On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240...@gmail.com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn  wrote:
>> Whilst it would be nice if miners in China can carry on forever regardless
>> of their internet situation, nobody has any inherent "right" to mine if they
>> can't do the job - if miners in China can't get the trivial amounts of
>> bandwidth required through their firewall and end up being outcompeted then
>> OK, too bad, we'll have to carry on without them.
>>
>> But I'm not sure why it should be a big deal. They can always run a node on
>> a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.

On Mon, Jun 1, 2015 at 7:02 PM, Chun Wang <1240...@gmail.com> wrote:
> On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn  wrote:
>> Whilst it would be nice if miners in China can carry on forever regardless
>> of their internet situation, nobody has any inherent "right" to mine if they
>> can't do the job - if miners in China can't get the trivial amounts of
>> bandwidth required through their firewall and end up being outcompeted then
>> OK, too bad, we'll have to carry on without them.
>>
>> But I'm not sure why it should be a big deal. They can always run a node on
>> a server in Taiwan and connect the hardware to it via a VPN or so.
>
> Ignorant. You seem do not understand the current situation. We
> suffered from orphans a lot when we started in 2013. It is now your
> turn. If Western miners do not find a China-based VPN into China, or
> if Western pools do not manage to improve their connectivity to China,
> or run a node in China, it would be them to have higher orphans, not
> us. Because we have 50%+.

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

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

On Mon, Jun 1, 2015 at 6:13 PM, Mike Hearn  wrote:
> Whilst it would be nice if miners in China can carry on forever regardless
> of their internet situation, nobody has any inherent "right" to mine if they
> can't do the job - if miners in China can't get the trivial amounts of
> bandwidth required through their firewall and end up being outcompeted then
> OK, too bad, we'll have to carry on without them.
>
> But I'm not sure why it should be a big deal. They can always run a node on
> a server in Taiwan and connect the hardware to it via a VPN or so.

Ignorant. You seem do not understand the current situation. We
suffered from orphans a lot when we started in 2013. It is now your
turn. If Western miners do not find a China-based VPN into China, or
if Western pools do not manage to improve their connectivity to China,
or run a node in China, it would be them to have higher orphans, not
us. Because we have 50%+.

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

[Bitcoin-development] Fwd: Block Size Increase Requirements

[Chun Wang]

On Sat, May 30, 2015 at 9:57 PM, Gavin Andresen  wrote:
>> Bad miners could attack us and the network with artificial
>> big blocks.
>
>
> How?
>
> I ran some simulations, and I could not find a network topology where a big
> miner producing big blocks could cause a loss of profit to another miner
> (big or small) producing smaller blocks:
>
> http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners
>
> (the 0.3% advantage I DID find was for the situation where EVERYBODY was
> producing big blocks).

If someone propagate a 20MB block, it will take at best 6 seconds for
us to receive to verify it at current configuration, result of one
percent orphan rate increase. Or, we can mine the next block only on
the previous block's header, in this case, the network would see many
more transaction-less blocks.

Our orphan rate is about 0.5% over the past few months. If the network
floods 20MB blocks, it can be well above 2%. Besides bandwidth, A 20MB
block could contain an average of 5 transactions, hundred of
thousands of sigops, Do you have an estimate how long it takes on the
submitblock rpccall?

For references, our 30Mbps bandwidth in Beijing costs us 1350 dollars
per month. We also use Aliyun and Linode cloud services for block
propagation. As of May 2015, the price is 0.13 U.S. dollars per GB for
100Mbps connectivity at Aliyun. For a single cross-border TCP
connection, it would be certainly far slower than 12.5 MB/s.

I think we can accept 5MB block at most.

(sorry forgot to cc to the mailing list)

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

Re: [Bitcoin-development] Block Size Increase Requirements

[Chun Wang]

Hello. I am from F2Pool. We are currently mining the biggest blocks on
the network. So far top 100 biggest bitcoin blocks are all from us. We
do support bigger blocks and sooner rather than later. But we cannot
handle 20 MB blocks right now. I know most blocks would not be 20 MB
over night. But only if a small fraction of blocks more than 10 MB, it
could dramatically increase of our orphan rate, result of higher fee
to miners. Bad miners could attack us and the network with artificial
big blocks. As yhou know, other Chinese pools, AntPool, BW, they
produces ASIC chips and mining mostly with their own machines. They do
not care about a few percent of orphan increase as much as we do. They
would continue their zero fee policy. We would be the biggest loser.
As the exchanges had taught us, zero fee is not health to the network.
Also we have to redevelop our block broadcast logic. Server bandwidth
is a lot more expensive in China. And the Internet is slow. Currently
China has more than 50% of mining power, if block size increases, I
bet European and American pools could suffer more than us. We think
the max block size should be increased, but must be increased
smoothly, 2 MB first, and then after one or two years 4 MB, then 8 MB,
and so on. Thanks.

On Fri, May 8, 2015 at 6:02 AM, Matt Corallo  wrote:
> OK, so lets do that. I've seen a lot of "I'm not entirely comfortable
> with committing to this right now, but think we should eventually", but
> not much "I'd be comfortable with committing to this when I see X". In
> the interest of ignoring debate and pushing people towards a consensus
> at all costs, ( ;) ) I'm gonna go ahead and suggest we talk about the
> second.
>
> Personally, there are several things that worry me significantly about
> committing to a blocksize increase, which I'd like to see resolved
> before I'd consider supporting a blocksize increase commitment.
>
>  * Though there are many proposals floating around which could
> significantly decrease block propagation latency, none of them are
> implemented today. I'd expect to see these not only implemented but
> being used in production (though I dont particularly care about them
> being all that stable). I'd want to see measurements of how they perform
> both in production and in the face of high packet loss (eg across the
> GFW or in the case of small/moderate DoS). In addition, I'd expect to
> see analysis of how these systems perform in the worst-case, not just
> packet-loss-wise, but in the face of miners attempting to break the system.
>
>  * I'd very much like to see someone working on better scaling
> technology, both in terms of development and in terms of getting
> traction in the marketplace. I know StrawPay is working on development,
> though its not obvious to me how far they are from their website, but I
> dont know of any commitments by large players (either SPV wallets,
> centralized wallet services, payment processors, or any others) to
> support such a system (to be fair, its probably too early for such
> players to commit to anything, since anything doesnt exist in public).
>
>  * I'd like to see some better conclusions to the discussion around
> long-term incentives within the system. If we're just building Bitcoin
> to work in five years, great, but if we want it all to keep working as
> subsidy drops significantly, I'd like a better answer than "we'll deal
> with it when we get there" or "it will happen, all the predictions based
> on people's behavior today say so" (which are hopefully invalid thanks
> to the previous point). Ideally, I'd love to see some real free pressure
> already on the network starting to develop when we commit to hardforking
> in a year. Not just full blocks with some fees because wallets are
> including far greater fees than they really need to, but software which
> properly handles fees across the ecosystem, smart fee increases when
> transactions arent confirming (eg replace-by-fee, which could be limited
> to increase-in-fees-only for those worried about double-spends).
>
> I probably forgot one or two and certainly dont want to back myself into
> a corner on committing to something here, but those are a few things I
> see today as big blockers on larger blocks.
>
> Luckily, people have been making progress on building the software
> needed in all of the above for a while now, but I think they're all
> very, very immature today.
>
> On 05/07/15 19:13, Jeff Garzik wrote:> On Thu, May 7, 2015 at 3:03 PM,
> Matt Corallo > > wrote:
> -snip-
>>> If, instead, there had been an intro on the list as "I think we should
>>> do the blocksize increase soon, what do people think?", the response
>>> could likely have focused much more around creating a specific list of
>>> things we should do before we (the technical community) think we are
>>> prepared for a blocksize increase.
>>
>> Agreed, but that is water under the bridge at this point.  You - rightly
>> - opened the topi