Andrew Baine [ARCHIVE] on Nostr: š Original date posted:2017-03-28 š Original message:The bitcoin ecosystem is ...
š
Original date posted:2017-03-28
š Original message: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 <
bitcoin-dev at lists.linuxfoundation.org> 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 <ajwest at gmail.com>
> > To: bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/a83fafa5/attachment-0001.html>;
š Original message: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 <
bitcoin-dev at lists.linuxfoundation.org> 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 <ajwest at gmail.com>
> > To: bitcoin-dev at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170328/a83fafa5/attachment-0001.html>;