Re: [bitcoin-dev] Fees and the block-finding process

[Angel Leon via bitcoin-dev]

tell that to people in poor countries, or even in first world countries.
The competitive thing here is a deal breaker for a lot of people who have
no clue/don't care for decentralization, they just want to send money from
A to B, like email.

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 I dont think Bitcoin being cheaper is the main characteristic of
 Bitcoin.  I think the interesting thing is trustlessness - being able
 to transact without relying on third parties.

 Adam


 On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
 bitcoin-dev@lists.linuxfoundation.org wrote:
  The only reason why Bitcoin has grown the way it has, and in fact the
 only
  reason why we're all even here on this mailing list talking about this,
 is
  because Bitcoin is growing, since it's better money than other money.
 One
  of the key characteristics toward that is Bitcoin being inexpensive to
  transact. If that characteristic is no longer true, then Bitcoin isn't
 going
  to grow, and in fact Bitcoin itself will be replaced by better money
 that is
  less expensive to transfer.
 
  So the importance of this issue cannot be overstated -- it's compete or
 die
  for Bitcoin -- because people want to transact with global consensus at
 high
  volume, and because technology exists to service that want, then it's
 going
  to be met. This is basic rules of demand and supply. I don't necessarily
  disagree with your position on only wanting to support uncontroversial
  commits, but I think it's important to get consensus on the criticality
 of
  the block size issue: do you agree, disagree, or not take a side, and
 why?
 
 
  On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille pieter.wui...@gmail.com
  wrote:
 
  On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
  bitcoin-dev@lists.linuxfoundation.org wrote:
 
  Hitting the limit in and of itself is not necessarily a bad thing. The
  question at hand is whether we should constrain that limit below what
  technology is capable of delivering. I'm arguing that not only we
 should
  not, but that we could not even if we wanted to, since competition will
  deliver capacity for global consensus whether it's in Bitcoin or in
 some
  other product / fork.
 
 
  The question is not what the technology can deliver. The question is
 what
  price we're willing to pay for that. It is not a boolean at this size,
  things break, and below it, they work. A small constant factor increase
  will unlikely break anything in the short term, but it will come with
 higher
  centralization pressure of various forms. There is discussion about
 whether
  these centralization pressures are significant, but citing that it's
  artificially constrained under the limit is IMHO a misrepresentation.
 It is
  constrained to aim for a certain balance between utility and risk, and
  neither extreme is interesting, while possibly still working.
 
  Consensus rules are what keeps the system together. You can't simply
  switch to new rules on your own, because the rest of the system will
 end up
  ignoring you. These rules are there for a reason. You and I may agree
 about
  whether the 21M limit is necessary, and disagree about whether we need a
  block size limit, but we should be extremely careful with change. My
  position as Bitcoin Core developer is that we should merge consensus
 changes
  only when they are uncontroversial. Even when you believe a more
 invasive
  change is worth it, others may disagree, and the risk from disagreement
 is
  likely larger than the effect of a small block size increase by itself:
 the
  risk that suddenly every transaction can be spent twice (once on each
 side
  of the fork), the very thing that the block chain was designed to
 prevent.
 
  My personal opinion is that we should aim to do a block size increase
 for
  the right reasons. I don't think fear of rising fees or unreliability
 should
  be an issue: if fees are being paid, it means someone is willing to pay
  them. If people are doing transactions despite being unreliable, there
 must
  be a use for them. That may mean that some use cases don't fit anymore,
 but
  that is already the case.
 
  --
  Pieter
 
 
 
  ___
  bitcoin-dev mailing list
  bitcoin-dev@lists.linuxfoundation.org
  https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
 
 ___
 bitcoin-dev mailing list
 bitcoin-dev@lists.linuxfoundation.org
 https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Angel Leon via bitcoin-dev]

I've been sharing a similar solution for the past 2 weeks. I think 2016
blocks is too much of a wait, I think we should look at the mean block size
during the last 60-120 minutes instead and avert any crisis caused by
transactional spikes that could well be caused by organic use of the
network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network
starts working as imagined, XYZ startup really kicks ass and succeeds in a
couple of major cities with major PR push)

Pseudo code in Python
https://gist.github.com/gubatron/143e431ee01158f27db4

My idea stems from a simple scalability metric that affects real users and
the desire to use Bitcoin:
Waiting times to get your transactions confirmed on the blockchain.
Anything past 45mins-1 hour should be unnacceptable.

Initially I wanted to measure the mean time for the transactions in blocks
to go from being sent by the user
(initial broadcast into mempools) until the transaction was effectively
confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins)

When blocks get full, people start waiting unnaceptable times for their
transactions to come through
if they don't adjust their fees. The idea is to avoid that situation at all
costs and keep the network
churning to the extent of its capabilities, without pretending a certain
size will be right at some
point in time, nobody can predict the future, nobody can predict real
organic usage peaks
on an open financial network, not all sustained spikes will come from
spammers,
they will come from real world use as more and more people think of great
uses for Bitcoin.

I presented this idea to measure the mean wait time for transactions and I
was told
there's no way to reliably meassure such a number, there's no consensus
when transactions are still
in the mempool and wait times could be manipulated. Such an idea would have
to include new timestamp fields
on the transactions, or include the median wait time on the blockheader
(too complex, additional storage costs)

This is an iteration on the next thing I believe we can all agree is 100%
accurately measured, blocksize.
Full blocks are the cause why many transactions would have to be waiting in
the mempool, so we should be able
to also use the mean size of the blocks to determine if there's a
legitimate need to increase or reduce the
maximum blocksize.

The idea is simple, If blocks are starting to get full past a certain
threshold then we double the blocksize
limit starting the next block, if blocks remain within a healthy bound,
transaction wait times should be as
expected for everyone on the network, if blocks are not getting that full
and the mean goes below a certain
threshold then we half the maximum block size allowed until we reach the
level we need.
Similar to what we do with hashing difficulty, it's something you can't
predict, therefore no fixed limits,
or predicted limits should be established.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9

[Angel Leon via bitcoin-dev]

so you want us to, (i) at the moment of payment decide wether to pay a tx
fee, or to include some data about what the transaction is about...
(ii) and (iii) are out of the question as you'd be forcing people to not
have privacy, which is one of the main reasons people use bitcoin, just
paying like cash.

then the rest goes down hill.

1. You want to add more data to a transaction, which would fill blocks even
faster.

2. The data will be on the blockchain, why in hell would anybody pay the
miners for it when you can just mine it yourself, or pay XYZ online service
to give you the tools you mention, and why would XYZ company pay miners for
the revenues of such service?

because... you want to change the Bitcoin license from MIT to something
else?

I'm sorry. this is dead on arrival, very unrealistic. Perhaps this will
work for some other coin where people accept all these orwellianism from
the start.

If you think there's much debate about blocksize you've no idea how things
would get at the mention of moving away from MIT into some sort of
commercial license, that would indeed destroy Bitcoin from being adopted as
it would enter into many many conflicts that would render it unusable by
lots of organizations.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP [104]: Replace Transaction Fees with Data, Discussion Draft 0.2.9

[Angel Leon via bitcoin-dev]

By increasing the size of blocks, transaction fees may not be available
to supplement mining revenue and so those who do not have access to cheap
or free power to mine;

why?
wouldn't a bigger block size actually allow for more transactions per
block, therefore more fees to be collected, and the cost spread out among
many more users (thus still keeping tx fees low). If anything, wouldn't
bigger blocksizes are needed to suplement the losses of coinbase rewards
being halfed.

http://twitter.com/gubatron

On Mon, Aug 17, 2015 at 12:39 PM, Ahmed Zsales via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Hello,

 Here we propose a long-term solution to replace mining rewards and
 transactions fees.

 BIP [104] is currently a discussion draft only.


 https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing

 Views and feedback welcome.

 Regards,

 Ahmed

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


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

Re: [bitcoin-dev] Fees and the block-finding process

[Angel Leon via bitcoin-dev]

- policy neutrality.
- It can't be censored.
- it can't be shut down
- and the rules cannot change from underneath you.

except it can be shutdown the minute it actually gets used by its inability
to scale.

what's the point of having all this if nobody can use it?
what's the point of going through all that energy and CO2 for a mere 24,000
transactions an hour?

It's clear that it's just a matter of time before it collapses.

Here's a simple proposal (concept) that doesn't pretend to set a fixed
block size limit as you can't ever know the demands the future will bring
https://gist.github.com/gubatron/143e431ee01158f27db4

We don't need to go as far as countries with hyper inflation trying to use
the technology to make it collapse, anybody here who has distributed
commercial/free end user software knows that any small company out there
installs more copies in a couple weeks than all the bitcoin users we have
at the moment, all we need is a single company/project with a decent amount
of users who are now enabled to transact directly on the blockchain to
screw it all up (perhaps OpenBazaar this winter could make this whole thing
come down, hopefully they'll take this debate and the current limitations
before their release, and boy are they coding nonstop on it now that they
got funded), the last of your fears should be a malicious government trying
to shut you down, for that to happen you must make an impact first, for now
this is a silly game in the grand scheme of things.

And you did sound pretty bad, all of his points were very valid and they
share the concern of many people, many investors, entrepreneurs putting
shitload of money, time and their lives on a much larger vision than that
of a network that does a mere 3,500 tx/hour, but some people seem to be
able to live in impossible or useless ideals.

It's simply irresponsible to not want to give the network a chance to grow
a bit more. Miners centralizing is inevitable given the POW based
consensus, hobbists-mining is only there for countries with very cheap
energy.

If things remain this way, this whole thing will be a massive failure and
it will probably take another decade before we can open our mouths about
cryptocurrencies, decentralization and what not, and this stubornness will
be the one policy that censored everyone, that shutdown everyone, that made
the immutable rules not matter.

Perhaps it will be Stellar what ends up delivering at this stubborn pace.

http://twitter.com/gubatron

On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 It follows then, that if we make a decision now which destroys that
 property, which makes it possible to censor bitcoin, to deny service, or to
 pressure miners into changing rules contrary to user interests, then
 Bitcoin is no longer interesting.

 You asked to be convinced of the need for bigger blocks. I gave that.
 What makes you think bitcoin will break when more people use it?

 Sent on the go, excuse the brevity.
 *From: *Mark Friedenbach
 *Sent: *Tuesday, 11 August 2015 08:10
 *To: *Thomas Zander
 *Cc: *Bitcoin Dev
 *Subject: *Re: [bitcoin-dev] Fees and the block-finding process

 On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:

 On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
  This is where things diverge. It's fine to pick a new limit or growth
  trajectory. But defend it with data and reasoned analysis.

 We currently serve about 0,007% of the world population sending maybe one
 transaction a month.
 This can only go up.

 There are about 20 currencies in the world that are unstable and showing
 early
 signs of hyperinflation. If even small percentage of these people
 cash-out and
 get Bitcoins for their savings you'd have the amount of people using
 Bitcoin
 as savings go from maybe half a million to 10 million in the space of a
 couple
 of months. Why so fast? Because all the world currencies are linked.
 Practically all currencies follow the USD, and while that one may stay
 robust
 and standing, the linkage has been shown in the past to cause
 chain-effects.

 It is impossible to predict how much uptake Bitcoin will take, but we have
 seen big rises in price as Cyprus had a bailin and then when Greece first
 showed bad signs again.
 Lets do our due diligence and agree that in the current world economy
 there
 are sure signs that people are considering Bitcoin on a big scale.

 Bigger amount of people holding Bitcoin savings won't make the transaction
 rate go up very much, but if you have feet on the ground you already see
 that
 people go back to barter in countries like Poland, Ireland, Greece etc.
 And Bitcoin will be an alternative to good to ignore.  Then transaction
 rates
 will go up. Dramatically.

 If you are asking for numbers, that is a bit tricky. Again; we are at
 0,007%... Thats like a f-ing rounding error in the world economy. You
 can't
 reason 

Re: [bitcoin-dev] Adjusted difficulty depending on relative blocksize

[Angel Leon via bitcoin-dev]

Like this?
https://gist.github.com/gubatron/143e431ee01158f27db4

http://twitter.com/gubatron

On Fri, Aug 14, 2015 at 5:59 AM, Jakob Rönnbäck 
bitcoin-dev@lists.linuxfoundation.org wrote:

 Greetings,

 a thought occurred to me that I would love to hear what some bitcoin
 experts think about.

 What if one were to adjust the difficulty (for individual blocks)
 depending on the relative size to the average block size of the previous
 difficulty period? (I apologize if i’m not using the correct terms, I’m not
 a real programmer, and I’ve only recently started to subscribe to the
 mailing list)


 In practice:

 1. calculate average block size for the previous difficulty period (is it
 2016-blocks?)
 2. when trying to find a new block adjust the difficulty by adding the
 relative size difference. For instance, if i’m trying to create a block
 half (or double) the size of the average block size for the previous
 difficulty period then my difficulty will be 2x the normal one… if I’m
 trying to make one that is 30% bigger (or smaller) then the difficulty is
 1.3 times the normal one


 Right now this would force miners to make blocks as close to 1mb as
 possible (since the block reward  fees). But unless I’m mistaken sometime
 in the future the block size should be adjusted to maximize the fees…


 Could the concept be useful somehow?

 I apologize if it’s been discussed before or if it’s a stupid idea, I
 would have run it by some other people, but I’m afraid I don’t know anyone
 that have any interest in bitcoin.

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

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

Re: [bitcoin-dev] Planned Obsolescence

[Angel Leon via bitcoin-dev]

Perhaps if there were a message that would nag your stdout or log output
letting you know there's a new version available, or N more versions
available and that you might be missing out on X security patches, Y
protocol improvements, depending on how far back you are, you'd be tempted
to upgrade, works for me in Ubuntu every time I log to my servers and I see
how far behind I am in terms of available updates.

Other thing done in open source projects to encourage updates, is to
automatically distribute (download) the patches and let the node operator
know an update has been downloaded for them, and let them know they're just
one step away from applying such update.
We do this for our bittorrent client. We don't ever want to do automatic
upgrades of our network, however, we want to make it painless to update.

For Bitcoin this could be done for the official binary distribution, would
not be an option for those that build from source.

On Thu, Dec 15, 2016 at 11:49 AM Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Dec 15, 2016 at 4:38 AM, Juan Garavaglia via bitcoin-dev
>  wrote:
> > Older node versions may generate issues because some upgrades will make
> > several of the nodes running older protocol versions obsolete and or
> > incompatible. There may be other hard to predict behaviors on older
> versions
> > of the client.
>
> Hard to predict or not, you can't force people to run newer software.
>
> > In order to avoid such wide fragmentation of "Bitcoin Core” node versions
> > and to help there be a more predictable protocol improvement process, I
> > consider it worth it to analyze introducing some planned obsolescence in
> > each new version. In the last year we had 4 new versions so if each
> version
> > is valid for about 1 year (52560 blocks) this may be a reasonable time
> frame
> > for node operators to upgrade. If a node does not upgrade it will stop
> > working instead of participating in the network with an outdated protocol
> > version.
>
> When you introduce anti-features like this in free software they can
> be trivially removed and they likely will.
>
> > These changes may also simplify the developer's jobs in some cases by
> > avoiding them having to deal with ancient versions of the client.
>
> There's a simpler solution for this which is what is being done now:
> stop maintaining and giving support for older versions.
> There's limited resources and developers are rarely interested in
> fixing bugs for very old versions. Users shouldn't expect things to be
> backported to old versions (if developers do it and there's enough
> testing, there's no reason not to do more releases of old versions, it
> is just rarely the case).
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

[Angel Leon via bitcoin-dev]

>Financially incentivising nodes is a really weird area because it would
allow someone to essentially automate the deployment of nodes. i.e. if a
node can pay for itself 100% (even at a lesser value, it just becomes
cheaper overall), you could write an application that uses an AWS API or a
digital ocean API to automatically deploy 100's of nodes. Which sounds
great but not if that person is malicious and wants to prevent the
community adopting proposals.

what other projects have done to avoid such attacks (while incentivizing
economically running full nodes) is to only distribute part of the block
rewards back such nodes if that node has committed/frozen a predetermined
amount of coins that can't be spent. This also leaves less liquidity for
market speculation and a incentives for long term commitments.

On Wed, Apr 19, 2017 at 5:14 AM udevNull via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'd like to add to this. There is definitely a barrier of entry with
> regards to setting up a full node. Unless you're living in a first world
> country, the bandwidth requirements alone, will outright prevent you from
> even setting up a full node (sync since genesis).
>
> To maintain that also becomes a sunk cost, as there is no financial
> incentive to run a node, only an idealogical one. Most of the people who
> benefit and will benefit from Bitcoin, are the un-banked. Which you will
> find in 3rd world countries, that don't have ISPs that provide the data
> packages, to cater for the requirements of running a full node. I'm sure
> many would like to, but simply cannot afford it.
>
> A user may not want to run a node at home, but rather on a digital ocean
> or AWS server, which they cannot afford to do either considering the
> bandwidth and storage costs associated with it. However, I don't think they
> should be excluded from participating in the network (supporting proposals,
> voicing their opinions, running their own wallets, writing their own
> applications on top of Bitcoin [which I think is extremely important]).
>
> So I would definitely be in favour of a small node of sorts. It will
> present us with some interesting technical challenges along the way but
> it's definitely worth while looking into.
>
> Financially incentivising nodes is a really weird area because it would
> allow someone to essentially automate the deployment of nodes. i.e. if a
> node can pay for itself 100% (even at a lesser value, it just becomes
> cheaper overall), you could write an application that uses an AWS API or a
> digital ocean API to automatically deploy 100's of nodes. Which sounds
> great but not if that person is malicious and wants to prevent the
> community adopting proposals.
> Just my 2 cents worth.
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Coins: A trustless sidechain protocol

[Angel Leon via bitcoin-dev]

> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
services, only their customers need to know those internal ledgers, and
sign off on the updates of those ledgers.

That's right, all you need to broadcast is a small proof, a non-interactive
blockchain suffix proof
https://eprint.iacr.org/2017/963.pdf



On Sun, Jan 12, 2020 at 7:33 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning Robin,
>
>
> > Good morning ZmnSCPxj,
> >
> > Thank you for your detailed feedback! Two topics:
> >
> > Lightning vs Sidechains
> >
> > 
> >
> > Why an either-or-solution, if we can connect sidechains via the LN to
> get the best of both worlds?
> >
> > The LN works exceptionally great under the following conditions:
> >
> > -   you're always online
> > -   you have BTC to manage your channels' inbound-capacity
> > -   you can afford BTC transactions
> > -   in your channel is much more than the minimum on-chain TX fees
> >
> > The next Billion users do not fit that category. They are on
> unreliable cell phone connections and do not have any BTC yet.
> > And the more popular Bitcoin becomes, the fewer people can
> afford LN channels. Even Eltoo requires your funds to be significantly
> higher than Bitcoin's TX fees, right?
> >
> > Already today, more and more services like tippin.me,
> BlueWallet, etc, provide custodial solutions.
> > For small amounts, custody is an acceptable workaround. And I
> love their usability. Install it and immediately I can send you $0.01. Yet,
> scaling their approach globally does not lead to desirable outcomes, since
> we'd be back to trusting banks with their Excel sheets.
> >
> > So let's make their internal ledgers public and trustless, via
> independent sidechains. Decentralized Blockchains do scale decently up to a
> couple Million UTXOs. So a couple thousand Sidechains is probably
> sufficient for a global medium of exchange. Cross-chain communication
> without requiring cross-chain validation is possible via atomic swaps and
> through Bitcoin's LN. That scales because it separates chain-validators
> from swap-validators.
> > Bitcoin's LN acts as the central settlement layer for efficient
> cross-chain transactions between all sidechains.
> >
> > So Endusers "living" in sidechains instead of directly in the LN
> has many advantages:
> >
> > -   no bitcoin blockspace required for on-boarding new users
> > -   no need to lock funds to provide inbound-capacity
> > -   no need to stay online or pay watch towers
> > -   no need to store channel histories
> > -   account balances can be much smaller than BTC TX fees
> >
> > Those are the exact same reasons why BlueWallet built their LndHub.
> But sidechains can be trustless. Also a generic protocol provides
> flexibility for sidechain innovations with arbitrary digital assets and
> consensus rules.
>
>
> Which is why I brought up multiparticipant offchain updateable
> cryptocurrency systems.
> The "channel factories" concepts does what you are looking for, except
> with better trust-minimization than sidechains can achieve.
> Just replace "sidechain" with either Decker-Wattenhofer or
> Decker-Russell-Osuntokun constructions.
> You can even use the Somsen "statechain" mechanism, which rides a
> Decker-Wattenhofer/Decker-Russell-Osuntokun construction, though its
> trust-minimization is only very very slightly better than federated
> sidechains.
>
> It is helpful to remember that Poon-Dryja, Decker-Wattenhofer,
> Decker-Russell-Osuntokun, and all other future such constructions, can host
> any contract that its lower layer can support.
> So if you ride a Poon-Dryja on top of the Bitcoin blockchain, you can host
> HTLCs inside the Poon-Dryja, since the Bitcoin blockchain can host HTLCs.
> Similarly, if you ride a Decker-Wattenhofer on top of the Bitcoin
> blockchain, you can host a Poon-Dryja inside the Decker-Wattenhofer, since
> the Bitcoin blockchain can host Poon-Dryja channels.
> This central insight leads one to conclude that anything you can put
> onchain, you an generally also put offchain, so why use a chain at all
> except as an ultimate anchor to reality?
> Poon-Dryja is strictly two-participant, while Decker-Wattenhofer limits
> the practical number of updates due to its use of decrementing relative
> timelocks: so you put the payment layer in a bunch of Poon-Dryja channels
> which support tons of updates each but only two participants per channel,
> and create a layer that supports changes to the channel topology (where
> changes to the channel connectivity are expected to be much rarer than
> payments) and is multiparticipant so you can *actually* scale.
>
> Instead of using sidechains, just use channel factories.
> You do not need to broadcast the entire internal ledgers of those
> services, only their customers need to know those