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 93A3CB4C for ; Wed, 29 Mar 2017 12:52:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE17CE3 for ; Wed, 29 Mar 2017 12:52:08 +0000 (UTC) Received: by mail-qk0-f169.google.com with SMTP id r142so11519069qke.2 for ; Wed, 29 Mar 2017 05:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stolze-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j99R7NQyecHSRmcPFBYGRaaLH3MDCR/mW1KJNpunGFA=; b=xDy2Z8kzIta2lhxDUgVWuz02p4mao59VOW9YjUCHbxLK4EYC/KoSkPed5+8qHtTZYj lOie6w20l7ikKrTw3sw30tX6MXgHj3KgzLza+n1VkN4Xzi+yeI7zjIcFsOITUstKYA0t XQ1WzjvYIVW+/12A9NcAYLjydLPTC6cEMY6LqwrxXF/jcTcPQY09A5nGD+SplQLhyCG/ rXVl/5kfXoAFVz9vF2JvgePTBcQr7J9WYsjJyPIHu5/zf/Zn/L7PgbUI2HkkkOA+4OkE XedgpTJtvbAC3S4P7D94F6un2SQHBe8f35QniOGY7Ug5B60tDEQ/GS/4gwu05TAB/EQb K7fA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=j99R7NQyecHSRmcPFBYGRaaLH3MDCR/mW1KJNpunGFA=; b=dZbK5Qg99UyqtgTHDYcjfBFQ6qNEZC+UKY3WlbrS+U6or6kHwU2REQgrVEcRgtYf72 N33XSUZ47jvDG8m5SMI90uorAvG+XZCf8ISheW9Gl4i91OXhq6gRZxY07GX+bjGq4YNL mQrnkF4IJY+K9j6LqY0eitTCRiSgyoXwdNNay0POaagRUy9cS4WyKodfeKFPWTpt2sik A3q9Tf+6k67D7e95s9MA5tWlCxqwokEmw/HGVIBTGzBSr+2ZSc+h4MiNevZ0fquYzbru abu7HvitUOHl+u5f3oLbrYKh5CJmyAheLwVv7rRG5ijNc0wd1ssdrHaU13XyWOp0HKyN 75mA== X-Gm-Message-State: AFeK/H2fcIpstlhCGY5sB4qts+XpnmAUY/1OuZFe2xWn6dhlxJym0Bv0zdSIS1k8zhQSMankJF6V7U0WACXZ+A== X-Received: by 10.233.237.23 with SMTP id c23mr343931qkg.190.1490791927861; Wed, 29 Mar 2017 05:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.78 with HTTP; Wed, 29 Mar 2017 05:51:47 -0700 (PDT) X-Originating-IP: [185.65.135.90] In-Reply-To: References: From: Martin Stolze Date: Wed, 29 Mar 2017 13:51:47 +0100 Message-ID: To: Andrew Baine Content-Type: text/plain; charset=UTF-8 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: Wed, 29 Mar 2017 13:48:57 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [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: Wed, 29 Mar 2017 12:52:09 -0000 Sure it will be somewhat controversial initially, however, "miners", will have additional incentive to listen to the network in order to get transactions. It's not taking away from your personal choice, it's adding additional choice to those that are disenfranchised by hash-power centralization. On Tue, Mar 28, 2017 at 3:57 PM, Andrew Baine wrote: > The bitcoin ecosystem is better off the more transactions are propogated > peer-to-peer than directly to miners. We want miners listening to the > network, not soliciting transactions directly from users. You whispering > your transactions to your miner-of-choice while I whisper to mine > contravenes a critical value-add of the peer-to-peer network in my opinion. > > On Tue, Mar 28, 2017 at 10:35 AM Martin Stolze via bitcoin-dev > wrote: >> >> Hi AJ, >> That's outstanding. I am glad to see that there is actually somebody >> who has made some progress. >> >> > "miners as service providers." >> Great idea! Block space as a resource is under-analyzed. >> >> > miner/pool's political positions, their consensus ideology, physical >> > location (yes some people would like only miners in particular countries to >> > mine their transactions) >> >> I am not joking when I say that in 3 to 8 years, I want to be able to >> verify my transaction through green blocks that are generated locally >> by my neighbor through the excess capacity of his solar panels or by >> an NGO pool that promotes solar deployment around the equator. >> >> > The main attitude right now is that people would like to 'support' >> > miners who signal for the features they care about. >> >> Yes, just selecting all SegWit signaling hash power instead of picking >> individual Authorities would be helpful on preferredminer.com >> >> > I strongly believe, whether the Bitcoin developer community facilitates >> > it or not, certain miners will become preferred by users. >> >> Absolutely, considering the recent language used in opinions by the >> ECB and drafts by the EU I see them assembling the artillery. I >> wouldn't be surprised if they start target practice next year. That >> will mean that commercial interest must have a way to transact on >> somewhat regulated space. >> >> > 1) By creating 'segregated mempools' where an authenticated third-party >> > like my web service Preferred Miner manages the access to pending >> > transactions destined for a specific set of miners >> >> I would call it regulated block space or regulated consensus space. I >> hope that we can do that on a deeper level, as part of the p2p >> protocol layer. >> >> > 2) by creating transactions where the mining fee is in one way or >> > another, an output to an address owned by the preferred miner(s). >> >> That's a distinct function, e.g. at least some communities charge a tax. >> [1] >> I fear it is more likely that a business, say Coinbase, will approach >> a "miner" and just say "we pay 100 USD for a KB to your bank account, >> here are our transactions with no fee". It will literally be an >> off-chain fee. That's what I mean by "secondary market". This would be >> one of the least appealing scenarios. >> >> > There are some terrible pitfalls with both of these methods. [...] >> >> Spot on, that's why this should receive some attention before it >> becomes urgent. I think there is much more to it that we are missing >> at the moment, e.g. Tom: "Using xthin/compact blocks miners only send >> a tiny version of a block which then causes the receiving node to >> re-create it using the memory pool." >> >> >> [1] http://thebitcoin.foundation/declaration.txt >> >> >> >> > From: AJ West >> > To: bitcoin-dev@lists.linuxfoundation.org >> > Cc: >> > Bcc: >> > Date: Mon, 27 Mar 2017 12:29:20 -0400 >> > Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering >> > Hi I'm AJ West, I made a service http://preferredminer.com which is a >> > proof-of-concept project designed to spur discussion on exactly this issue >> > of "miners as service providers." >> > >> > The current status is that Bitcoin end users are looking to support >> > specific miners, whether that's because they agree with a miner/pool's >> > political positions, their consensus ideology, physical location (yes some >> > people would like only miners in particular countries to mine their >> > transactions) and the list of reasons goes on. The main attitude right now >> > is that people would like to 'support' miners who signal for the features >> > they care about. >> > >> > I strongly believe, whether the Bitcoin developer community facilitates >> > it or not, certain miners will become preferred by users. In summary, there >> > are realistically two proposed ways of providing this service in the >> > present-day situation: 1) By creating 'segregated mempools' where an >> > authenticated third-party like my web service Preferred Miner manages the >> > access to pending transactions destined for a specific set of miners, and 2) >> > by creating transactions where the mining fee is in one way or another, an >> > output to an address owned by the preferred miner(s). >> > >> > There are some terrible pitfalls with both of these methods. The first >> > being that you have to trust a lot of people, including the 3rd party (me) >> > and the pools to work in your users' interest ("don't give my transactions >> > to other miners or broadcast to mempool please"). Then there are the extra >> > fees users will have to pay to offset the risk of a miner losing out for >> > having to send the network a not-yet-broadcasted transaction. And finally, >> > the other method requires that they be larger transactions, and a directory >> > of mining pools' receiving addresses for outputs must be maintained. Then >> > you have to hope the miner will be setup to scoop in your transaction >> > knowing it's got a fee for them. Plus, how many nodes going forward are >> > going to hold what seem to be 0-fee transactions in mempool (because the fee >> > is in the outputs)? >> > >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev