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 --]
next prev parent 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$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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