From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 529695A7 for ; Mon, 20 Mar 2017 20:12:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com [209.85.220.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 28E782FA for ; Mon, 20 Mar 2017 20:12:57 +0000 (UTC) Received: by mail-qk0-f173.google.com with SMTP id p64so119942250qke.1 for ; Mon, 20 Mar 2017 13:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stolze-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=VvRU7CFn+ekyjVv5ea2yOEq2wvDOJk1l417oCxuED4I=; b=ynW+cfPyHSR4oXL6ZcAVl1wzXTVXHPpqv2R9lZbC2vZR41V575eA5QpZpdEHWTNKED TNTm2LPNyLCu4IN/5hVi+6QFEEqFXusAP5Z5xGD/8q+1IU93/TbVjSlHs4UdeVMDr3Tq NXflZv0igRNwiG34CqIBJfz5a1fQC0fV5nmD0XP3HaOiqIh8NXG6M+uMmRbdZxWixKc3 HtCnA/GoHOrDzMsk3u3iPLPPwdO/uEAue3niO7N8/olN2/JDuysMldIFz7MPP7jrluRf /6yn1rnjVpgZZA3Jw1SHErZYQ5LCCmF+hRBFQ+fxAKq1ELTo2kRLzNGbwE2gTwyjONvj 8kUg== 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 :content-transfer-encoding; bh=VvRU7CFn+ekyjVv5ea2yOEq2wvDOJk1l417oCxuED4I=; b=umXJQ7n2KrrqpEeocki10e9r7di0bRo34S4EuP58NudWZijda/zgOuty3X3MG8bxoC HBs7+eM4ZVpKVlqt9j+GuPLXz16bYlS8r3K/+QqFADsUB4HShC0EWxizBuSApoROQ/L+ IoCMU0ULYNtT0rHw0QcOojwCOrt/8rn1hBNnlAgVC3zaazs6iTejWvj2j1nWUiyJRMSH HmmqdBeUX9M7s7XN++iM+wkmFxagdDmAPZazdgSX+bc7UBhNjRKLeYtn/Z0tlmfaFtQA w57K1QvMQLlPhJiQHWfpHSff3CUU7mMOruUnybng4Kh2V5syjPbVBnOjBjDE7Vb0E3Te q24g== X-Gm-Message-State: AFeK/H0obbbtApLCVr10zg4cK7FBRO1bUSeblSFsDdygCYqFh2l+c8x2Dxna5M3LpGpYP2Fqy3W6ut42uA5Sbg== X-Received: by 10.55.54.5 with SMTP id d5mr29401342qka.9.1490040776730; Mon, 20 Mar 2017 13:12:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.78 with HTTP; Mon, 20 Mar 2017 13:12:36 -0700 (PDT) X-Originating-IP: [185.65.132.110] From: Martin Stolze Date: Mon, 20 Mar 2017 20:12:36 +0000 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Mon, 20 Mar 2017 20:37:39 +0000 Subject: [bitcoin-dev] Inquiry: Transaction Tiering 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: Mon, 20 Mar 2017 20:12:59 -0000 Hi Team, I would like to find out what the current consensus on transaction tiering = is. Background: The current protocol enables two parties to transact freely, however, transaction processors (block generators) have the authority to discriminate participants arbitrarily. This is well known and it is widely accepted that transaction processors may take advantage of this with little recourse. It is the current consensus that the economic incentives in form of transaction fees are sufficient because the transaction processing authorities are assumed to be guided by the growth of Bitcoin and the pursuit of profit. We can establish that a transaction processing authority does not need to actually process transactions and reigns sovereign over the block space they govern. [1] For further discussion I will refer to a transaction processor more aptly as "Block Space Authority" (BSA). Currently, a user can only signal to all BSA=E2=80=99s (via the mempool) it= s desire to include her transaction into the ledger. A user can not signal to specific BSA=E2=80=99s, and thus, can not easily carry out busine= ss in jurisdictions that conform to the users understanding of best practice. As a participant in the economy in general and of Bitcoin in particular, I desire an ability to decide where I transact. The current state of Bitcoin does not allow me to choose my place of business. As a consequence, I try to learn what would be the best way to conduct my business in good faith. [2] I have certain minimum requirements towards the constitution of the block space like transparency, forward guidance and risk management. More poignantly, it could also include due diligence to ensure that child labor is not involved in the maintenance of a specific block space, or that the specific block space does not utilize nuclear energy or sources at least 80% of the expended energy from solar power. Obviously, preferences can vary widely. I don=E2=80=99t think there is any way to discard the desire of users to choose their place of business, especially under the consideration that BSA=E2=80=99s have the discretion to choose users transactions already= . I have identified the following options along the lines of Lawrence Lessig's concept of Cyberspace: [3] 1. Law: Bilateral Agreement Users engage directly with BSA=E2=80=99s to process their transaction. Transactions are routed around the mempool. A likely outcome of this solution is the emergence of brokers that sell off block space in a sort of secondary market. Wallets may negotiate on behalf of their users. This model has obvious downsides as it involves new middlemen, increases transaction cost beyond the current market price (speculation) and potentially reduces performance. 2. Architecture: Remove transaction fees If only the block reward functions to incentivise transaction processing, no differentiation is useful. However, spam/empty blocks could not be prevented and Bitcoin would have to be entirely redesigned, potentially losing its censorship resistance. 3. Market: Direct Communication Through the core client, BSA=E2=80=99s can offer individual mempools that users can choose to advertise their transactions to. Different BSA=E2=80=99= s could receive different transaction fees for the same transaction in their respective mempool to reflect the preference of the user. In Conclusion: In the long term, it is likely that a clearer differentiation of BSA=E2=80=99s will become important. Today, BSA=E2=80=99= s communicate rarely and it appears that their raison d'etre is not necessarily motivated by good faith towards Bitcoin as a whole. [4] As we move forward it is not just important to attract opportunistic players that win an individual game but good players that are invited to play again in order to win a set of all possible games. BSA=E2=80=99s establish their authority on cheap access to capital in the f= orm of electricity and hardware and the consent and trust of users who expect BSA's to respect and maintain the ledgers integrity. In 3 to 8 years, when Bitcoin leaves it=E2=80=99s bootstrapping phase, the incentives will squarely fall on the later. [5] Subsequently it seems prudent to allow BSA=E2=80=99s to compete for business on other factors tha= n price. Hence my question: What is the current stance of core developers regarding the facilitation of direct communication between users and BSA=E2=80=99s, possibly through a transaction tiering model? Sincerely, Martin Stolze [1] BSA rules sovereign: (https://twitter.com/JihanWu/status/70447683956613= 5298) [2] No direct attribution but solid foundation for business logic since 1899: =C2=A7242 ff BGB (https://www.gesetze-im-internet.de/englisch_bgb/englisch_bgb.html#p0726) [3] Lessig, Code. "And Other Laws of Cyberspace, Version 2.0." (2006). [4] The pursuit of profit can come at the expense of Bitcoin: (https://twitter.com/ToneVays/status/835233366203072513) [5] Satoshi Nakamoto: "Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees [...]"