Joel Joonatan Kaartinen [ARCHIVE] on Nostr: ð Original date posted:2015-05-07 ð Original message:Having observed the ...
ð
Original date posted:2015-05-07
ð Original message:Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through the backlog when 100% full is hit for a while. So, while
pondering this, I got an idea that I think has a chance of working that I
can't remember seeing suggested anywhere.
How about basing the maximum valid size for a block on the total bitcoin
days destroyed in that block? That should still stop transaction spam but
naturally expand the block size when there's a backlog of real
transactions. It'd also provide for an indirect mechanism for increasing
the maximum block size based on fees if there's a lot of fees but little
bitcoin days destroyed. In such a situation there'd be incentive to pay
someone to spend an older txout to expand the maximum. I realize this is a
rather half baked idea, but it seems worth considering.
- Joel
On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> This *is* urgent and needs to be handled right now, and I believe Gavin
> has the best approach to this. I have heard Gavin's talks on increasing
> the block size, and the two most persuasive points to me were:
>
> (1) Blocks are essentially nearing "full" now. And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way (I believe it was due to the
> inconsistent time between blocks). I think Gavin said that his simulations
> showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is
> where things start to behave poorly for certain classes of transactions.
> In other words, we're very close to the effective limit in terms of
> maintaining the current "standard of living", and with a year needed to
> raise the block time this actually is urgent.
>
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea. It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability). But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur. If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail. Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure). We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
> You can argue that side chains and payment channels could alleviate this.
> But how far off are they? We're going to hit effective 1MB limits long
> before we can leverage those in a meaningful way. Even if everyone used
> them, getting a billion people onto the system just can't happen even at 1
> transaction per year per person to get into a payment channel or move money
> between side chains.
>
> We get asked all the time by corporate clients about scalability. A limit
> of 7 tps makes them uncomfortable that they are going to invest all this
> time into a system that has no chance of handling the economic activity
> that they expect it handle. We always assure them that 7 tps is not the
> final answer.
>
> Satoshi didn't believe 1 MB blocks were the correct answer. I personally
> think this is critical to Bitcoin's long term future. And I'm not sure
> what else Gavin could've done to push this along in a meaninful way.
>
> -Alan
>
>
>
> On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that people
>> must find and alternative right now. Quite a lot here do not believe there
>> is any urgency, nor that there is an immanent problem that has to be solved
>> before the sky falls in.
>>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all over
> again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/fa4f0644/attachment.html>;
ð Original message:Having observed the customer support nightmare it tends to cause for a
small exchange service when 100% full blocks happen, I've been thinking
that the limit really should be dynamic and respond to demand and the
amount of fees offered. It just doesn't feel right when it takes ages to
burn through the backlog when 100% full is hit for a while. So, while
pondering this, I got an idea that I think has a chance of working that I
can't remember seeing suggested anywhere.
How about basing the maximum valid size for a block on the total bitcoin
days destroyed in that block? That should still stop transaction spam but
naturally expand the block size when there's a backlog of real
transactions. It'd also provide for an indirect mechanism for increasing
the maximum block size based on fees if there's a lot of fees but little
bitcoin days destroyed. In such a situation there'd be incentive to pay
someone to spend an older txout to expand the maximum. I realize this is a
rather half baked idea, but it seems worth considering.
- Joel
On Thu, May 7, 2015 at 10:31 PM, Alan Reiner <etotheipi at gmail.com> wrote:
> This *is* urgent and needs to be handled right now, and I believe Gavin
> has the best approach to this. I have heard Gavin's talks on increasing
> the block size, and the two most persuasive points to me were:
>
> (1) Blocks are essentially nearing "full" now. And by "full" he means
> that the reliability of the network (from the average user perspective) is
> about to be impacted in a very negative way (I believe it was due to the
> inconsistent time between blocks). I think Gavin said that his simulations
> showed 400 kB - 600 kB worth of transactions per 10 min (approx 3-4 tps) is
> where things start to behave poorly for certain classes of transactions.
> In other words, we're very close to the effective limit in terms of
> maintaining the current "standard of living", and with a year needed to
> raise the block time this actually is urgent.
>
> (2) Leveraging fee pressure at 1MB to solve the problem is actually really
> a bad idea. It's really bad while Bitcoin is still growing, and relying on
> fee pressure at 1 MB severely impacts attractiveness and adoption potential
> of Bitcoin (due to high fees and unreliability). But more importantly, it
> ignores the fact that for a 7 tps is pathetic for a global transaction
> system. It is a couple orders of magnitude too low for any meaningful
> commercial activity to occur. If we continue with a cap of 7 tps forever,
> Bitcoin *will* fail. Or at best, it will fail to be useful for the vast
> majority of the world (which probably leads to failure). We shouldn't be
> talking about fee pressure until we hit 700 tps, which is probably still
> too low.
>
> You can argue that side chains and payment channels could alleviate this.
> But how far off are they? We're going to hit effective 1MB limits long
> before we can leverage those in a meaningful way. Even if everyone used
> them, getting a billion people onto the system just can't happen even at 1
> transaction per year per person to get into a payment channel or move money
> between side chains.
>
> We get asked all the time by corporate clients about scalability. A limit
> of 7 tps makes them uncomfortable that they are going to invest all this
> time into a system that has no chance of handling the economic activity
> that they expect it handle. We always assure them that 7 tps is not the
> final answer.
>
> Satoshi didn't believe 1 MB blocks were the correct answer. I personally
> think this is critical to Bitcoin's long term future. And I'm not sure
> what else Gavin could've done to push this along in a meaninful way.
>
> -Alan
>
>
>
> On 05/07/2015 02:06 PM, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that people
>> must find and alternative right now. Quite a lot here do not believe there
>> is any urgency, nor that there is an immanent problem that has to be solved
>> before the sky falls in.
>>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all over
> again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
>
> _______________________________________________
> Bitcoin-development mailing listBitcoin-development at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/fa4f0644/attachment.html>;