From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z54RP-0003CC-8A for bitcoin-development@lists.sourceforge.net; Wed, 17 Jun 2015 03:55:07 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.115 as permitted sender) client-ip=62.13.149.115; envelope-from=pete@petertodd.org; helo=outmail149115.authsmtp.co.uk; Received: from outmail149115.authsmtp.co.uk ([62.13.149.115]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Z54RN-0007q7-B3 for bitcoin-development@lists.sourceforge.net; Wed, 17 Jun 2015 03:55:07 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5H3swqd094351; Wed, 17 Jun 2015 04:54:58 +0100 (BST) Received: from muck ([212.183.128.195]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5H3sqfe037335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Jun 2015 04:54:56 +0100 (BST) Date: Wed, 17 Jun 2015 04:54:45 +0100 From: Peter Todd To: Aaron Voisine Message-ID: <20150617035445.GA23826@muck> References: <9834E283-727C-47F7-A3D0-667951727E5F@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: X-Server-Quench: 9ead8373-14a4-11e5-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwUUEkAaAgsB AmMbW1BeVVl7XGQ7 aQtTcwRVYVRPXQ10 UUFMXVdaExppT1gE fh1dE08ndwZBe311 K0VjXnJTEk0vJBJ1 QUlXCGwCNGN9aWFK VV1RIQRQbQNKfBpM agF+V3ZZYitlM3Bw LCUyIzs2PDMaJClL TwUKNVcfR1o+Vich SgseHDIpBgUMTSIu M1QsK0IXG0cXd3UO eVAmVV9QPRgICUUQ fQlLBykcLF4HXCct Fh5BFU4XCjEYTyBG AXUA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 212.183.128.195/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1Z54RN-0007q7-B3 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2015 03:55:07 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote: > Thanks Alex, the work you've pointed out is helpful. Limiting mempool size > should at least prevent nodes from crashing. When I looked a few days ago= I > only found a few old PRs that seemed to have fallen by the wayside, so th= is > new one is encouraging. BTW it's worth working out how many $ in fees you need for a given amount of MB worth of mempool. At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5 worth of fees - kinda ridiculous when a block earns a miner $6250 in revenue. Pretty much all txs pay significantly higher rates - more like 100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to fill to pay the fees, and in practice will probably quickly get higher. https://github.com/bitcoin/bitcoin/pull/6281 > I can respond in the PR comments if it's more appropriate there, but I > believe ejecting tx from mempools rather than preemptively refusing them > according to standard network wide propagation rules will result in spott= y, > inconsistent tx propagation, and possibly a large increase in tx > re-broadcasts, so if those haven't been addressed they will need to be. It > would also be prudent to run some simulations to see what other issues are > going to pop-up. See above - filling the mempool like that will be both a slow process, and require lots of funds. Equally, once full, the sensible thing to do is raise the minimum relay fee appropriately, so those transactions that pay too low a fee will simply be rejected. It'd be reasonable to tell peers that, and what the minimum fee needed for acceptance would be for that particular node. > We're currently using CPFP already in breadwallet when spending unconfirm= ed > non-change inputs. A small percentage of hashing power is using it, but > enough to get a transaction unstuck assuming breadwallet's fee calculation > is better than the sender's. > The problem with RBF is that there's currently no way to tell if your tx > has been picked up by miners or not in order to know if you need to repla= ce > it. Miners broadcasting partial block solutions would be helpful in this > regard, but only for tx in the currently-being-worked-on block, not for tx > that won't be picked up until the block after. If miners were to eject tx > that were previously being worked on in favor of higher fee tx, then that > causes another set of problems for wallets that thought their tx was going > to get in but then it doesn't. The other problem with RBF is that users > don't know up front what fee they're actually going to pay which is a big > blow to real world usability. Also mobile wallets will have to sign lots = of > tx up front and rely on a service to replace as necessary. And this is all > just on the send side. For an interactive, mobile wallet, the best thing to do is estimate the fee correctly the first time, using RBF as a follow up mechanism only if needed. For other users - e.g. exchanges handling customer withdrawals - using RBF more agressively to get the minimum possible fee may make sense. > On the receive side it's much worse since you can't > rely on the sender to do the replacing. The real problem seems to be the > fact that RBF is an interactive iterative process rather than a > send-and-forget one. In any case, the *existance* of RBF makes no difference to any of these problems; RBF does make solving the easier. You can always choose to not use it after all, resulting in the same "send-and-forget" process. Having it available allows mistakes to be fixed after the fact, always an improved user experience over not being able to re-bid for block space. Incidentally, if my FSS-RBF bug bounty isn't collected in the next week or two, we'll likely have a major double-digits % of hashing power mining FSS-RBF soon after. http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08= 122.html > What you really need is some way to tell up-front, is a transaction going > to get mined with a high probability? That problem seems really difficult > to solve with fixed-size blocks that are full. Have you looked at the fee estimation code in Bitcoin Core? I have no reason to think it doesn't basically speaking work. Of course, SPV wallets will need a semi-trusted third party to securely get that data, but this seems to be a fundemental problem in a decentralized network - the purpose of the blockchain itself is to prove that some data was published to some audience, an analogous problem to proving to the SPV wallet that their transaction actually reached miners and they actually are considering it for inclusion. Guaranteed reliable transaction processing is only possible in centralized environments that can make service guarantees. > If the goal is simply to > reduce or limit the growth of the blockchain, then there are much simpler > solutions, which is why I've advocated for the blocksize increase, follow= ed > by tx selection and propagation rule changes to create fee pressure. Few if any of those mechanisms can be deployed in a consensus-critical way that is resistant to attack; the blocksize limit is needed to - among other things - resist attacks by one miner on another to reduce the competitors profitability. Without an explicit limit tx selection and propagation rule changes can be gamed. --=20 'peter'[:-1]@petertodd.org 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778 --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVgO+CXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udz9RQf+MLazxyrr313kvIn1jN+VIRDW 3i63zg6j3oyF5D1OSoRrwxwsYJKRxIXSP4p8WaNyr3MMf0U9oFeovHqwWthXO1Ow Gv/7NlBkTHslxgbWpZ8WoXdCR3ywgp9/pFJqbnnJ2iO+aawyOB2iBpXKk2qWNScM SQFEUl4gPeuwqYZprGSwOOo2gCh5lJVWSmbzx1YdShW7fVj1XZAiEqmV5YvZkuIf TSBsgqdNlhYgfIwOz7yKjBH6zHGKi7CVQ/hOpJMTUuPiOcayCrBaXT7xbSoXns4d i8kpG1b0TMB3P2YjkyqOeC8OW77gURXmGMCkvo81dOssvBvADiqoK+FkFo2UWA== =MN0D -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--