Benjamin [ARCHIVE] on Nostr: š Original date posted:2015-06-27 š Original message:On Sat, Jun 27, 2015 at ...
š
Original date posted:2015-06-27
š Original message:On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 07:46:55PM +0200, Benjamin wrote:
> > There is no ensured Quality of service, is there? If you "bid" higher,
> then
> > you don't know what you are going to get. Also because you have no way of
> > knowing what *others* are bidding. Only if you have auctions (increasing
> > increments) you can establish a feedback loop to settle demand and
> supply.
> > And the supply side doesn't adapt. Adapting supply would help resolve
> parts
> > of the capacity problem.
>
> There's lots of markets where there is no assured quality of service,
> and where the bids others are making aren't known. Most financial
> markets work that way - there's only ever probabalistic guarantees that
> for a given amount of money you'll be able to buy a certain amount of
> gold at any given time for instance. Similarly for nearly all
> commodities the infrastructure required to mine those commodities has
> very little room for short, medium, or even long-term production
> increases, so whatever the production supply is at a given time is
> pretty much fixed.
>
hmm? if the current ask for 1 ounce of gold is 100$, then you need to bid
100$ to get 1 ounce of gold. If tomorrow everyone agree 1ounce of gold
should be worth 200$, then the bid moves accordingly. of course production
changes based on prices. otherwise the economy would not function. if price
of some stuff goes up, more people produce that stuff. in terms of a price
for a transaction and the use of a blockchain, unfortunately there is not a
way to just add computational supply. that's an inherent weakness of how
blockchains are structured. ideally it would be as simple as demanding more
resources as in scaling a webservices with AWS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/ef46ab91/attachment.html>;
š Original message:On Sat, Jun 27, 2015 at 7:54 PM, Peter Todd <pete at petertodd.org> wrote:
> On Sat, Jun 27, 2015 at 07:46:55PM +0200, Benjamin wrote:
> > There is no ensured Quality of service, is there? If you "bid" higher,
> then
> > you don't know what you are going to get. Also because you have no way of
> > knowing what *others* are bidding. Only if you have auctions (increasing
> > increments) you can establish a feedback loop to settle demand and
> supply.
> > And the supply side doesn't adapt. Adapting supply would help resolve
> parts
> > of the capacity problem.
>
> There's lots of markets where there is no assured quality of service,
> and where the bids others are making aren't known. Most financial
> markets work that way - there's only ever probabalistic guarantees that
> for a given amount of money you'll be able to buy a certain amount of
> gold at any given time for instance. Similarly for nearly all
> commodities the infrastructure required to mine those commodities has
> very little room for short, medium, or even long-term production
> increases, so whatever the production supply is at a given time is
> pretty much fixed.
>
hmm? if the current ask for 1 ounce of gold is 100$, then you need to bid
100$ to get 1 ounce of gold. If tomorrow everyone agree 1ounce of gold
should be worth 200$, then the bid moves accordingly. of course production
changes based on prices. otherwise the economy would not function. if price
of some stuff goes up, more people produce that stuff. in terms of a price
for a transaction and the use of a blockchain, unfortunately there is not a
way to just add computational supply. that's an inherent weakness of how
blockchains are structured. ideally it would be as simple as demanding more
resources as in scaling a webservices with AWS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/ef46ab91/attachment.html>;