Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-07 📝 Original message:On Thu, May 07, 2015 at ...
📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote:
> On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> > I would very much like to find some concrete course of action that we can
> > come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> > how much transaction volume the main Bitcoin blockchain will be able to
> > support over the next eleven years."
>
> Mhmm, I hadn't thought about this. This makes sense and actually
> explains the urgency on taking a decision better than anything else
> I've heard.
I've spent a lot of time talking to companies about this, and the
problem is telling them that isn't actually very useful; knowing the
supply side of the equation isn't all that useful if you don't know the
demand side. Problem is we don't really have a good handle on what
Bitcoin will be used for in the future, or even for that matter, what
it's actually being used for right now.
As we saw with Satoshidice before and quite possibly will see with smart
contracts (escrows, futures, etc) it's easy for a relatively small
number of use cases to drive a significant amount of transaction volume.
Yet, as Wladimir and others point out, the fundemental underlying
architecture of the blockchain has inherently poor O(n^2) scaling, so
there's always some level of demand where it breaks, and/or incentivizes
actors in the space to push up against "safety stops" like soft
blocksize limits and get them removed.
Note how the response previously to bumping up against soft policy
limits was highly public calls(1) at the first hint of touble: "Mike
Hearn: Soft block size limit reached, action required by YOU"
1) https://bitcointalk.org/index.php?topic=149668.0
--
'peter'[:-1]@petertodd.org
000000000000000002761482983864328320badf24d137101fab9a5861a59d30
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/e4fcb555/attachment.sig>;
📝 Original message:On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote:
> On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> > I would very much like to find some concrete course of action that we can
> > come to consensus on. Some compromise so we can tell entrepreneurs "THIS is
> > how much transaction volume the main Bitcoin blockchain will be able to
> > support over the next eleven years."
>
> Mhmm, I hadn't thought about this. This makes sense and actually
> explains the urgency on taking a decision better than anything else
> I've heard.
I've spent a lot of time talking to companies about this, and the
problem is telling them that isn't actually very useful; knowing the
supply side of the equation isn't all that useful if you don't know the
demand side. Problem is we don't really have a good handle on what
Bitcoin will be used for in the future, or even for that matter, what
it's actually being used for right now.
As we saw with Satoshidice before and quite possibly will see with smart
contracts (escrows, futures, etc) it's easy for a relatively small
number of use cases to drive a significant amount of transaction volume.
Yet, as Wladimir and others point out, the fundemental underlying
architecture of the blockchain has inherently poor O(n^2) scaling, so
there's always some level of demand where it breaks, and/or incentivizes
actors in the space to push up against "safety stops" like soft
blocksize limits and get them removed.
Note how the response previously to bumping up against soft policy
limits was highly public calls(1) at the first hint of touble: "Mike
Hearn: Soft block size limit reached, action required by YOU"
1) https://bitcointalk.org/index.php?topic=149668.0
--
'peter'[:-1]@petertodd.org
000000000000000002761482983864328320badf24d137101fab9a5861a59d30
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/e4fcb555/attachment.sig>;