Paul Sztorc [ARCHIVE] on Nostr: 📅 Original date posted:2017-06-22 📝 Original message:Hi Erik, I don't think ...
📅 Original date posted:2017-06-22
📝 Original message: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 at gmail.com
> <mailto:truthcoin at 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.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170622/3ba60e24/attachment.html>;
📝 Original message: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 at gmail.com
> <mailto:truthcoin at 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.
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170622/3ba60e24/attachment.html>;