Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 86FAF49B for ; Fri, 22 Dec 2017 08:26:15 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f193.google.com (mail-qk0-f193.google.com [209.85.220.193]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E2127CA for ; Fri, 22 Dec 2017 08:26:14 +0000 (UTC) Received: by mail-qk0-f193.google.com with SMTP id b132so3904145qkc.13 for ; Fri, 22 Dec 2017 00:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hBBqr90o108/yV6u63076rHxxmtO6Cv8lA/Co7tl0Xo=; b=har2Q6O0FCxpVSH27i7/5seLBVYoPUXRw6YLf45CCr17y0/Cf4Lpb+rgjnY7G8wWhH kLiTIXVdiPRRSz5M18ndUo1jUgtl0BBp1j5qZRwUfzdLX1GNLcq8DjdrD0YS69GplyGb ugqovyVipTN0o7MRJWf1A1GrecZUuoIEHq/H8YyUxagGwoep6xONFffK02pGbUOAmPIU 0hGOsnFzpHKlBBne6VPBqfuNvJAR9i4zOiCW6VsHZVNLXArHiEZc6y2ldmkT49CxDKrV qvwz+rbnTqbM1HJU2qGdFr0eM7nLOUI4w6v7rZGM5OR6InNmlhMZn6nMwEd11vZGMFEa +NAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hBBqr90o108/yV6u63076rHxxmtO6Cv8lA/Co7tl0Xo=; b=mbH9Nps2WmX+SY42JB7qekFWwOlmFrZDMz/hGha8o7I0ywdWBbAzoh9/E/64c0rO1u kBEd61heHD/OQ3DVNnEmUJPGB5LkqWmJsPWZyYrtr/kvBDGROPKKZGw4pDoNcmiON+ZZ aep4Bmi4Zt5cDuZrP1gv6lvryEmW4U7EoJ2QFMOSBLnxFV/e/avQyXVk0gkyTgcJBtuv 4vI6LReoFReBfeV5sSU2Z+CaF5/pfHXSlPxFXu4Pt8VzqvTWLH544cKUslIP7SbLv2uI b5pukmxzKEHBtQtsdOjX1mNoDNSQdDrMyt4sx30sOD4J+fDoAwQw6IDmLwiugwtZgKFD Targ== X-Gm-Message-State: AKGB3mKgG1H7a0kct1ExUhhKhxooPRcCEQXJVHEOikRism1oenUjaR+T FZQNmKOYA1TzTW4ZfJ+GbF6T63JXHjFFME6BvgJWT87L X-Google-Smtp-Source: ACJfBotH5y7xESf8aerBcER0z99dv9GNeOjmQNiP0jZnrqdq/5mUihXaODHMGB6Ymmk82I2Z6SCYyiQJsr4yrt8HQt4= X-Received: by 10.55.101.198 with SMTP id z189mr16818005qkb.46.1513931173579; Fri, 22 Dec 2017 00:26:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.9 with HTTP; Fri, 22 Dec 2017 00:26:12 -0800 (PST) From: oscar Date: Fri, 22 Dec 2017 09:26:12 +0100 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 22 Dec 2017 15:07:31 +0000 Subject: [bitcoin-dev] what do you think about having a maximum fee rate? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2017 08:26:15 -0000 Hello, I'm not a bitcoin developer, but I'd like to receive feedback on what I think is a serious problem. Hope I'm not wasting your time. I'm also sure this was already discussed, but google doesn't give me any good result. Let me explain: I think that the current incentive system doesn't really align with the way miners are distributed (not very decentralized, due to pools and huge asic producers). I think big miners are incentivized to spam the network with low(ish) fee transactions, thereby forcing regular users into paying extremely high fees to be able to get their transactions confirmed. Obviously this is the result of insufficient mining decentralization, but as I will try to show, such an attack could be profitable even if you are controlling just 5-10% of the hashing power, which could always be easy for a big player and with some collusion. Let's look at some numbers: https://i.imgur.com/sCn4eDG.png These are 10 blocks mined yesterday, and they all have rewards hugely exceeding the normal 12.5 mining output. Even taking the lowest value of 20, it's a nice 60% extra profit for the miner. Let's say you control 10% of the hashing power, and you spam enough transactions to fill 144 blocks (1 day's worth) at 50 satoshi/byte, losing just 72 BTC in fees. (blocksize-in-bytes * fee-per-byte * Nblocks)/satoshis-in-btc => (1e6 * 50 * 144)/1e8 => 72 At the same time you will discover about 144*0.1=14.4 blocks per day. Assuming the situation we see in the previous screenshot is what happens when you have a mempool bigger than one day's worth of blocks, you would get 20-12.5=7.5 extra BTC per block, which is 14.4*7.5=108 BTC, given your investment of 72 to spam the mempool. 32 btc extra profit. The big assumption here is that spamming 1 day of backlog in the 50satoshi/b range will get people to compete enough to push 7.5 btc of fees in each block, but: * https://jochen-hoenicke.de/queue/#30d this seems to confirm that about half the mempool is in the 50satoshi/b range or less. * https://blockchain.info/pools there are miners that control more than 10% * if you get enough new real transactions, it's not necessary to spam a full 144 blocks worth each day, probably just ~50 would be enough, cutting the spam cost substantially * other miners could be playing the same game, helping you spam and further reduce the costs of the attack * you actually get 10% of the fees back by avoiding mining your spam transactions in your own blocks * most of the spam transactions won't actually end up in blocks if there is enough pressure coming from real usage This seems to indicate that you would actually get much higher profit margins than my estimates. **PLEASE** correct me if my calculations or my assumptions are wrong. You might also say that doing this would force users out of the system, decreasing the value of btc and disincentivizing miners from continuing. On the other hand, a backlogged mempool could create the impression of high(er) usage and increase scarcity by slowing down movements, which could actually push the price upwards. Of course, it's impossible to prove that this is happening. But the fact that it is profitable makes me believe that it is happening. I see some solutions to this, all with their own downsides: - increasing block size every time there is sustained pressure this attack wouldn't work, but the downsides have already been discussed to death. - change POW Not clear it would fix this, aside from stimulating terrible infighting. Controlling 5 to 10% of the hashing power seems too easy, and I don't think it would be practical to change pow every time that happens, as it would prevent the development of a solid POW support. - protocol level MAX transaction fee I personally think this would totally invalidate the attack by making the spam more expensive than the fees you would recover. There already is a minimum fee accepted by the nodes, at 1 satoshi per byte. The maximum fee could be N times the minimum, maybe 100-200. Meaning a maximum of 1-2btc in total fee rewards when the block size is 1mb. Of course the actual values need more analysis, but 2btc - together with the deflationary structure - seems enough to continue motivating miners, without giving unfair advantage. Yes, this would make it impossible to spend your way out of a congested mempool. But if the mempool stays congested after this change, you could have a bigger confidence that it's coming from real usage or from someone willfully burning money, making a block size increase much more justified. Hope to hear your opinion, have a nice day. oscar