public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Paul Sztorc <truthcoin@gmail.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
Date: Thu, 22 Jun 2017 09:27:25 -0400	[thread overview]
Message-ID: <cd96b01e-46ca-9328-2a0a-82ba96d5183c@gmail.com> (raw)
In-Reply-To: <CAJowKgKT2rn3N3L+79JEY_uNfKDewcmgkiEB2mJYx1mg+YjGCQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3025 bytes --]

Hi Erik,

I don't think that your design is competitive. Why would users tolerate
a depreciation of X% per year, when there are alternatives which do not
require such depreciation? It seems to me that none would.

Paul

On 6/20/2017 9:38 AM, Erik Aronesty wrote:
> - a proof-of-burn sidechain is the ultimate two-way peg.   you have to
> burn bitcoin *or* side-chain tokens to mine the side chain.   the size
> of the burn is the degree of security.    i actually wrote code to do
> randomized blind burns where you have a poisson distribution
> (non-deterministic selected burn).    there is no way to game it...
> it's very similar to algorand - but it uses burns instead of staking
>
> - you can then have a secure sidechain that issues a mining reward in
> sidechain tokens, which can be aggrregated and redeemed for bitcoins.
>   the result of this is that any bitcoins held in the sidechain
> depreciate in value at a rate of X% per year.   this deflation rate
> pays for increased security
>
> - logically this functions like an alt coin, with high inflation and
> cheap transactions.   but the altcoin is pegged to bitcoin's price
> because of the pool of unredeemed bitcoins held within the side chain.
>
>
>
> On Tue, Jun 20, 2017 at 7:54 AM, Paul Sztorc <truthcoin@gmail.com
> <mailto:truthcoin@gmail.com>> wrote:
>
>     Hi Erik,
>
>     As you know:
>
>     1. If a sidechain is merged mined it basically grows out of the
>     existing Bitcoin mining network. If it has a different PoW
>     algorithm it is a new mining network.
>     2. The security (ie, hashrate) of any mining network would be
>     determined by the total economic value of the block. In Bitcoin
>     this is (subsidy+tx_fees)*price, but since a sidechain cannot
>     issue new tokens it would only be (tx_fees)*price.
>
>     Unfortunately the two have a nasty correlation which can lead to a
>     disastrous self-fulfilling prophecy: users will avoid a network
>     that is too insecure; and if users avoid using a network, they
>     will stop paying txn fees and so the quantity (tx_fees)*price
>     falls toward zero, erasing the network's security. So it is quite
>     problematic and I recommend just biting the bullet and going with
>     merged mining instead.
>
>     And, the point may be moot. Bitcoin miners may decide that, given
>     their expertise in seeking out cheap sources of power/cooling,
>     they might as well mine both/all chains. So your suggestion may
>     not achieve your desired result (and would, meanwhile, consume
>     more of the economy's resources -- some of these would not
>     contribute even to a higher hashrate).
>
>     Paul
>
>
>
>
>     On 6/19/2017 1:11 PM, Erik Aronesty wrote:
>>     It would be nice to be able to enforce that a drivechain *not*
>>     have the same POW as bitcoin.
>>
>>     I suspect this is the only way to be sure that a drivechain
>>     doesn't destabilize the main chain and push more power to miners
>>     that already have too much power.
>>
>>
>
>


[-- Attachment #2: Type: text/html, Size: 5585 bytes --]

  reply	other threads:[~2017-06-22 13:27 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22  6:17 [bitcoin-dev] Drivechain -- Request for Discussion Paul Sztorc
2017-05-22 13:33 ` Peter Todd
2017-05-22 15:30   ` Paul Sztorc
2017-05-28 21:07     ` Peter Todd
     [not found]       ` <CAJowKgJjNaoWVc=QXfOqH3OdBPoKm3qkfUNpKV6oKLSRx_fD0g@mail.gmail.com>
     [not found]         ` <CAJowKgKFMXDE-yzEqYkY7c+80Mgn+iL9ZRNJbv9WhUBR32EvRg@mail.gmail.com>
2017-05-29  5:54           ` Erik Aronesty
2017-05-30  5:11       ` Paul Sztorc
2017-06-09 21:54         ` Sergio Demian Lerner
2017-06-10 16:28           ` Paul Sztorc
2017-05-22 14:39 ` ZmnSCPxj
2017-05-22 16:19   ` Paul Sztorc
2017-05-22 19:12     ` Tier Nolan
2017-05-22 20:00       ` Paul Sztorc
2017-05-23  9:51         ` Tier Nolan
2017-05-23 14:22           ` Paul Sztorc
2017-05-24  8:50             ` Tier Nolan
2017-05-24 10:05               ` Tier Nolan
2017-05-24 17:32                 ` CryptAxe
2017-05-25 22:08                   ` Tier Nolan
2017-06-18 14:36               ` Chris Stewart
2017-06-18 21:27                 ` CryptAxe
     [not found]                   ` <CAGL6+mGZZ=wG8P_DNj3PXVf==mLjJwA_bESh0_UdH2iVBY7GQA@mail.gmail.com>
2017-06-19 15:41                     ` Chris Stewart
2017-05-23  0:13     ` ZmnSCPxj
2017-05-23 14:12       ` Paul Sztorc
2017-05-23 23:26         ` ZmnSCPxj
2017-06-10 17:04 ` [bitcoin-dev] Drivechain RfD -- Follow Up Paul Sztorc
2017-06-18 21:30   ` Tao Effect
2017-06-19 16:04     ` Paul Sztorc
     [not found]       ` <CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
2017-06-20 11:54         ` Paul Sztorc
2017-06-20 13:38           ` Erik Aronesty
2017-06-22 13:27             ` Paul Sztorc [this message]
2017-06-22 13:45               ` Erik Aronesty
2017-06-22 20:30                 ` Paul Sztorc
2017-06-23 14:19                   ` Erik Aronesty
2017-06-23 14:51                     ` Moral Agent
2017-06-23 18:11                     ` Paul Sztorc
2017-07-12 22:43       ` Tao Effect
2017-07-13  0:26         ` Paul Sztorc
2017-07-13  1:15           ` Tao Effect
2017-07-13  2:58             ` Paul Sztorc
2017-07-13  3:24               ` Tao Effect
2017-07-13 15:39                 ` Paul Sztorc
2017-07-13 13:17               ` Hampus Sjöberg
2017-07-13 17:04                 ` Paul Sztorc

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cd96b01e-46ca-9328-2a0a-82ba96d5183c@gmail.com \
    --to=truthcoin@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=erik@q32.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox