Re: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn

2020-06-25 Thread ZmnSCPxj via bitcoin-dev
Good morning CS,

The difficulty is not so much the proof-of-whatever, but rather, the peg itself.
My understanding of your pegout from sidechain to mainchain is that this pegout 
is very low-bandwidth, i.e. only a tiny amount can be pegged out at each 
mainchain block.
This suggests to me that the sidecoin can still drop lower than maincoin during 
times when overall side-to-main flows are higher than main-to-side flows.
(atomic swaps cannot *maintain* a peg, they can only follow a peg if it exists; 
if the peg is weak, atomic swaps cannot strengthen it.
this is because atomic swaps allow a non-1:1 exchange rate, as in 
cross-currency atomic swaps.)


In any case, from my reading of your text, I seem, the goal is scaling 
("acceptable option for lower value tx").
I studied sidechains some years ago, and, came to the conclusion that 
sidechains are not good for scaling.
We already know that blockchains do not scale well (excessive bandwidth use, 
permanent records needed to support newcomers); thus, the scaling solution for 
cryptocurrency cannot be via **more** blockchains.
Hence, Lightning Network.

In Lightning Network, every channel is a consensus system between two 
participants, hence every channel is a 2-of-2 (i.e. requires consensus of both 
participants to advance).
We use atomic swaps to transfer between channels and the blockchain.
The channel construction requires reference to an ultimate arbiter of any 
dispute/non-consensus between the channel participants; this is provided by the 
blockchain layer off which the channel is based.

Thus blockchain for arbitration, channels for scaling.


Regards,
ZmnSCPxj


> Hi everyone,
>
> I am hoping to get a critique on a proposal of how to construct childchains 
> "on-top" of Bitcoin without requiring any changes to Bitcoin itself nor 
> requiring any user or miner to be aware of them.
>
> The childchain is Bitcoin-aware and simulates the properties of Proof of Work 
> by requiring continuous burning of Bitcoin in return for the fees on the 
> childchain.
>
> The childchain tip is selected by highest total accumulated Bitcoin burnt 
> (with goal to simulate total accumulated work) for that full chained set of 
> childchain block commits.
>
> The only asset on the childchain is a 2-way-peg coin that's secured in value 
> without oracles or collateral by requiring that each valid child chain block 
> must not only burn Bitcoin, but must always use a small % of the burnt amount 
> to deterministically reimburse withdrawals from the childchain.
>
> Childchain -> mainchain :: user burns the child-BTC and is added to 
> withdrawal queue filled as part of validity requirements by childchain 
> "miners" until filled 1:1 on mainchain or more. Note that occasionally 
> overpaying a widthdrawal does not break 1:1 peg as there's no fixed size 1:1 
> pool of coins necessary.
>
> mainchain -> childchain :: user burns BTC (independent of mining childchain) 
> and is issued equivalent 1:1 child-BTC on the childchain
>
> While childchains are less secure than the mainchain, both the childchain 
> security and the 2-way-peg accuracy might be an acceptable option for lower 
> value tx on scale determined by the burning rate. 
>
> Childchains would replace the need for any additional Proof of Work chains 
> for new blockchains to introduce any complexity (e.g. mimblewimble 
> childchain).
>
> They would effectively use Proof of Work done on Bitcoin as proxy for 
> unforgeable costliness and benefit from Bitcoin's censorship resistance and 
> data availability. Large numbers of low value tx that might be priced out of 
> using the main chain could possibly in bulk provide enough childchain fees 
> combined through childchain miners to afford much higher mainchain fees like 
> "batching for fees".
>
> It also has the "benefits" claimed by proof of stake like no energy 
> consumption without relying on internal permissions or tokens, trusted 
> distributions, or centralizing mechanisms like staking by simulating proof of 
> work. It should allow both growing the Bitcoin ecosystem and replace the need 
> to create alternative cryptocurrencies just to make a new blockchain.
>
> More detailed write up available here: 
> https://bitcointalk.org/index.php?topic=5214173.0  
>
> I am hoping for a review if there's an overlooked issue or maybe interest to 
> create a proof of concept.
>
> Thank you
> -CS


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn

2020-06-25 Thread Cloud Strife via bitcoin-dev
Hi everyone,

I am hoping to get a critique on a proposal of how to
construct childchains "on-top" of Bitcoin without requiring any changes to
Bitcoin itself nor requiring any user or miner to be aware of them.

The childchain is Bitcoin-aware and simulates the properties of Proof of
Work by requiring continuous burning of Bitcoin in return for the fees on
the childchain.

The childchain tip is selected by highest total accumulated Bitcoin burnt
(with goal to simulate total accumulated work) for that full chained set of
childchain block commits.

The only asset on the childchain is a 2-way-peg coin that's secured in
value without oracles or collateral by requiring that each valid child
chain block must not only burn Bitcoin, but must always use a small % of
the burnt amount to deterministically reimburse withdrawals from the
childchain.

Childchain -> mainchain :: user burns the child-BTC and is added to
withdrawal queue filled as part of validity requirements by childchain
"miners" until filled 1:1 on mainchain or more. Note that occasionally
overpaying a widthdrawal does not break 1:1 peg as there's no fixed size
1:1 pool of coins necessary.

mainchain -> childchain :: user burns BTC (independent of mining
childchain) and is issued equivalent 1:1 child-BTC on the childchain

While childchains are less secure than the mainchain, both the childchain
security and the 2-way-peg accuracy might be an acceptable option for lower
value tx on scale determined by the burning rate.

Childchains would replace the need for any additional Proof of Work chains
for new blockchains to introduce any complexity (e.g. mimblewimble
childchain).

They would effectively use Proof of Work done on Bitcoin as proxy for
unforgeable costliness and benefit from Bitcoin's censorship resistance and
data availability. Large numbers of low value tx that might be priced out
of using the main chain could possibly in bulk provide enough childchain
fees combined through childchain miners to afford much higher mainchain
fees like "batching for fees".

It also has the "benefits" claimed by proof of stake like no energy
consumption without relying on internal permissions or tokens, trusted
distributions, or centralizing mechanisms like staking by simulating proof
of work. It should allow both growing the Bitcoin ecosystem and replace the
need to create alternative cryptocurrencies just to make a new blockchain.

More detailed write up available here:
https://bitcointalk.org/index.php?topic=5214173.0

I am hoping for a review if there's an overlooked issue or maybe interest
to create a proof of concept.

Thank you
-CS
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] MAD-HTLC

2020-06-25 Thread Bastien TEINTURIER via bitcoin-dev
Good morning list,

This is an interesting and simple idea, thanks for sharing this paper!

However I think there are a couple of important issues (but it could be me
misunderstanding):

* the assumption that the mempool is a shared resource is flawed: it's
entirely possible
  to have very different mempools in different areas of the network, for a
potentially long
  period of time (see the RBF pinning thread [1]), and an attacker can
leverage this fact
* a corollary is that Bob may not know that Alice has published her
transaction, and will
  end up publishing his timeout tx, unknowingly giving the two preimages to
the miners
* a corollary of that is a very unhealthy incentive to miners, when they
receive an HTLC
  success tx, to always wait for the timeout before confirming the
transaction, in hope that
  they'll receive the second preimage and will be able to claim the funds
for themselves
  (whereas currently they don't gain anything by waiting before confirming
these txs)

To be fair the paper states that it doesn't address issues of malicious
miners or an attacker
colluding with a miner, but I think that even honest miners now have an
unhealthy incentive
regarding htlc success confirmation.

Let me know if I misunderstood something, or if you have ideas on how to
explore that
threat model in the future.

Cheers,
Bastien

[1]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002639.html



Le jeu. 25 juin 2020 à 14:45, Nadav Ivgi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> Hi ZmnSCPxj,
>
> You are of course correct. I had considered the effect of reorgs, but the
> email seemed to be getting too lengthy to mention that too.
>
> You would need a few spare blocks in which Bob won't be accused of bribery
> as a safety margin, which does reduce the time frame in which Alice can get
> her transaction confirmed in order to have a valid bribery fraud. This
> seems workable if the time frame was long enough (over a few hours should
> be sufficient, assuming we consider reorgs of over 3-4 blocks to be
> unlikely), but could indeed be problematic if the time frame is already
> short to begin with.
>
> Nadav
>
> On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj  wrote:
>
>> Good morning Nadav,
>>
>> > > I and some number of Lightning devs consider this to be sufficient
>> disincentive to Bob not attacking in the first place.
>> >
>> > An additional disincentive could be introduced in the form of bribery
>> proofs for failed attempts.
>> >
>> > If we assume that "honest" users of the LN protocol won't reveal their
>> timelocked transactions before reaching the timelock expiry (they shouldn't
>> anyway because standard full node implementations won't relay them), we can
>> prove that Bob attempted bribery and failed to an outside observer by
>> showing Bob's signed timelocked transaction, spending an output that was in
>> reality spent by a different transaction prior to the locktime expiry,
>> which should not be possible if Bob had waited.
>>
>>
>> Unfortunately this could be subject to an inversion of this attack.
>>
>> Alice can wait for the timelock to expire, then bribe miners to prevent
>> confirmation of the Bob timelocked transaction, getting the Alice
>> hashlocked transaction confirmed.
>>
>> Now of course you do mention "prior to the locktime expiry" but there is
>> now risk at around locktime.
>>
>> Particularly, "natural" orphaned blocks and short-term chainsplits can
>> exist.
>> Bob might see that the locktime has arrived and broadcast the signed
>> timelocked transaction, then Alice sees the locktime has not yet arrived
>> (due to short-term chainsplits/propagation delays) and broadcast the signed
>> hashlocked transaction, then in the end the Alice side of the short-term
>> chainsplit is what solidifies into reality due to random chance on which
>> miner wins which block.
>> Then Bob can now be accused of bribery, even though it acted innocently;
>> it broadcasted the timelock branch due to a natural chainsplit but Alice
>> hashlocked branch got confirmed.
>>
>> Additional complications can be added on top to help mitigate this edge
>> case but more complex == worse in general.
>> For example it could "prior to locktime expiry" can ignore a few blocks
>> before the actual timelock, but this might allow Bob to mount the attack by
>> initiating its bribery behavior earlier by those few blocks.
>>
>> Finally, serious attackers would just use new pseudonyms, the important
>> thing is to make pseudonyms valuable and costly to lose, so it is
>> considered sufficient that LN nodes need to have some commitment to the LN
>> in the form of actual channels (which are valuable, potentially
>> money-earning constructs, and costly to set up).
>>
>> Other HTLC-using systems, such as the "SwapMarket" being proposed by
>> Chris Belcher, could use similar disincentivizing; I know Chris is planning
>> a fidelity bond system for SwapMarket makers, for example, which would
>> mimic 

Re: [bitcoin-dev] MAD-HTLC

2020-06-25 Thread Nadav Ivgi via bitcoin-dev
Hi ZmnSCPxj,

You are of course correct. I had considered the effect of reorgs, but the
email seemed to be getting too lengthy to mention that too.

You would need a few spare blocks in which Bob won't be accused of bribery
as a safety margin, which does reduce the time frame in which Alice can get
her transaction confirmed in order to have a valid bribery fraud. This
seems workable if the time frame was long enough (over a few hours should
be sufficient, assuming we consider reorgs of over 3-4 blocks to be
unlikely), but could indeed be problematic if the time frame is already
short to begin with.

Nadav

On Thu, Jun 25, 2020 at 7:04 AM ZmnSCPxj  wrote:

> Good morning Nadav,
>
> > > I and some number of Lightning devs consider this to be sufficient
> disincentive to Bob not attacking in the first place.
> >
> > An additional disincentive could be introduced in the form of bribery
> proofs for failed attempts.
> >
> > If we assume that "honest" users of the LN protocol won't reveal their
> timelocked transactions before reaching the timelock expiry (they shouldn't
> anyway because standard full node implementations won't relay them), we can
> prove that Bob attempted bribery and failed to an outside observer by
> showing Bob's signed timelocked transaction, spending an output that was in
> reality spent by a different transaction prior to the locktime expiry,
> which should not be possible if Bob had waited.
>
>
> Unfortunately this could be subject to an inversion of this attack.
>
> Alice can wait for the timelock to expire, then bribe miners to prevent
> confirmation of the Bob timelocked transaction, getting the Alice
> hashlocked transaction confirmed.
>
> Now of course you do mention "prior to the locktime expiry" but there is
> now risk at around locktime.
>
> Particularly, "natural" orphaned blocks and short-term chainsplits can
> exist.
> Bob might see that the locktime has arrived and broadcast the signed
> timelocked transaction, then Alice sees the locktime has not yet arrived
> (due to short-term chainsplits/propagation delays) and broadcast the signed
> hashlocked transaction, then in the end the Alice side of the short-term
> chainsplit is what solidifies into reality due to random chance on which
> miner wins which block.
> Then Bob can now be accused of bribery, even though it acted innocently;
> it broadcasted the timelock branch due to a natural chainsplit but Alice
> hashlocked branch got confirmed.
>
> Additional complications can be added on top to help mitigate this edge
> case but more complex == worse in general.
> For example it could "prior to locktime expiry" can ignore a few blocks
> before the actual timelock, but this might allow Bob to mount the attack by
> initiating its bribery behavior earlier by those few blocks.
>
> Finally, serious attackers would just use new pseudonyms, the important
> thing is to make pseudonyms valuable and costly to lose, so it is
> considered sufficient that LN nodes need to have some commitment to the LN
> in the form of actual channels (which are valuable, potentially
> money-earning constructs, and costly to set up).
>
> Other HTLC-using systems, such as the "SwapMarket" being proposed by Chris
> Belcher, could use similar disincentivizing; I know Chris is planning a
> fidelity bond system for SwapMarket makers, for example, which would mimic
> the properties of LN channels (costly to set up, money-earning).
>
> Regards,
> ZmnSCPxj
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] MAD-HTLC

2020-06-25 Thread Nadav Ivgi via bitcoin-dev
> I and some number of Lightning devs consider this to be sufficient
disincentive to Bob not attacking in the first place.

An additional disincentive could be introduced in the form of bribery
proofs for failed attempts.

If we assume that "honest" users of the LN protocol won't reveal their
timelocked transactions before reaching the timelock expiry (they shouldn't
anyway because standard full node implementations won't relay them), we can
prove that Bob attempted bribery and failed to an outside observer by
showing Bob's signed timelocked transaction, spending an output that was in
reality spent by a different transaction prior to the locktime expiry,
which should not be possible if Bob had waited.

These proofs would be gossiped, and lightning network participants could
choose not to peer with Bob when they see them. This might require some
sort of a scoring/reputation scheme that makes it harder for Bob to attack
with new throw-away identities to be effective. (i.e. limiting your
exposure to peers to some BTC amount based on their historical public
channels records, using fidelity bonds, etc.)

Bob could still send these bribery transactions privately to selected
miners, but not making them public would greatly reduce the participating
miners' confidence that there is enough participating hashpower for the
attack to be profitable.

Nadav

On Thu, Jun 25, 2020 at 4:38 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Stanga et al,
>
>
> > > Hi ZmnSCPxj,
> > >
> > > Thank you for taking the time to respond, these are very good points.
> Responses inline.
> > >
> > > On Tue, Jun 23, 2020 at 12:48 PM ZmnSCPxj 
> wrote:
> > >
> > > > Good morning Itay, Ittay, and Matan,
> > > >
> > > > I believe an unstated assumption in Bitcoin is that miners are
> short-sighted.
> > > >
> > > > The reasoning for this assumption is:
> > > >
> > > > * Deployment of new mining hardware controlled by others may occur
> at any time you do not control.
> > > >   * Thus, any transactions you leave on the table are potentially
> taken by somebody else and not by you.
> > > >   * Sudden changes in hashpower distribution may reduce your
> expected future earnings, so any future theoretical earnings should be
> discounted (*in addition to* expected return-on-investment on getting money
> you can invest *now*).
> > >
> > > Our analysis assumes constant difficulty, i.e., no significant changes
> of the miners set. Indeed, hash-rate changes typically occur at a much
> larger granularity than your average HTLC timeout. For instance, we noticed
> plenty of lightning nodes use timeouts of a day. So, we do not consider
> optimization at infinity, just a day ahead, and within this time frame all
> the factors you mentioned are not expected to dramatically change.
> > >
> > > That being said, it would be interesting to analyze the effect of
> miners joining during the HTLC duration. Intuitively, this shouldn’t affect
> the results, as those new miners have the same incentive to wait for the
> higher-paying tx.
>
> We already know that hashrate tends to trend upwards, and that we do not
> expect hashrate to fall except for occasional transients.
>
> The expectation is not that new miners have different incentives.
> Instead, the expectation is that current miners discount future possible
> gains because in the future, they expect to have less hashrate share than
> right now.
>
> The only trustless way for Bob to bribe miners into deferring Alice tx is
> to attach the bribe to the future confirmation of the Bob tx, thus Bob is
> offering future-coins, not present-coins like Alice can offer, and the fact
> that miners expect an overall uptrend in total hashrate (leading to an
> overall downtrend in their hashrate share) means that miners discount the
> Bob offered future-coins.
> The discounting is proportional to the time delay involved, as a larger
> delay implies greater reduction in hashrate share.
>
> This discounting is, again, *in addition to* natural discounting a.k.a. "I
> will gladly pay you Thursday for a hamburger today", the hamburger seller
> will want some pretty stiff assurances plus a bigger payment on Thursday
> for giving you a hamburger today, due to expected returns on investment.
>
>
> > >
> > >
> > > > It also strikes me that, in a world with RBF and CPFP, the same
> endpoint (i.e. miners earn the entire fund of the HTLC) is achieved by
> existing HTLCs, without the additional branch and script opcodes needed by
> MAD-HTLC.
> > > > For example, if an HTLC is confirmed but the hashlock-claiming
> transaction is not being confirmed (because miners are holding it up
> because Bob is offering a much higher fee in the future for the
> timelock-claiming transaction), then Alice can, regardless of the reason
> why it is not being confirmed, bump up the fee with RBF or CPFP.
> > > >
> > > > If the fee bump offered by Alice is sufficiently large, then miners
> will start re-preferring