[Lightning-dev] Goodbye Bitcoin

[Prayank via Lightning-dev]

Hello kanzure mailing list and ln mailing list,

This is my last email and I won't be involved in anything related to Bitcoin. 
If my username is used on GitHub or other places it can be considered someone 
else using it.


-- 
Prayank

A3B1 E430 2298 178F
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via Lightning-dev]

he option to set defaults that are 
>> > widely used.
>>
>>
>> Bitcoin Core with different versions are used at any point and not sure if 
>> this will ever change.
>>
>> https://luke.dashjr.org/programs/bitcoin/files/charts/security.html
>>
>> https://www.shodan.io/search/facet.png?query=User-Agent%3A%2FSatoshi%2F+port%3A%228333%22=product
>>
>> > I think if certain defaults can bolster the security of Lightning (and 
>> > possibly other Layer 2 projects) at no cost to full node users with no 
>> > interest in those protocols we should discuss what those defaults should 
>> > be.
>>
>>
>> This is the assumption which I don't agree with and hence asked some 
>> questions in my email. A new RBF policy used by default in Core will not 
>> improve the security of projects that are vulnerable to multiple RBF 
>> policies or rely on these policies in a way that affects their security. 
>>
>> Maybe some experiments on signet might help in knowing more issues 
>> associated with multiple RBF policies.
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> Feb 13, 2022, 21:16 by michaelfolk...@protonmail.com:
>>
>>> Hi Prayank
>>>
>>> > 1.Is Lightning Network and a few other layer 2 projects vulnerable to 
>>> > multiple RBF policies being used?
>>>
>>> Clearly the security of the Lightning Network and some other Layer 2 
>>> projects are at least impacted or partly dependent on policy rules in a way 
>>> that the base blockchain/network isn't. As I (and others) have said on many 
>>> occasions ideally this wouldn't be the case but it is best we can do with 
>>> current designs. I (and others) take the view that this is not a reason to 
>>> abandon those designs in the absence of an alternative that offers a 
>>> strictly superior security model. Going back to a model where *all* 
>>> activity is onchain (or even in less trust minimized protocols than 
>>> Lightning) doesn't seem like the right approach to me.
>>>
>>> > 2.With recent discussion to change things in default RBF policy used by 
>>> > Core, will we have multiple versions using different policies? Are users 
>>> > and especially miners incentivized to use different versions and 
>>> > policies? Do they have freedom to use different RBF policy?
>>>
>>> Without making policy rules effective consensus rules users (including 
>>> miners) are free to run different policy rules. I think it is too early to 
>>> say what the final incentives will be to run the same or differing 
>>> policies. Research into Lightning security is still nascent and we have no 
>>> idea whether alternative Layer 2 projects will thrive and whether they will 
>>> have the same or conflicting security considerations to Lightning. 
>>>
>>> As you know the vast majority of the full nodes on the network currently 
>>> run Bitcoin Core. Whether that will change in future and whether this a 
>>> good thing or not is a whole other discussion. But the reality is that with 
>>> such strong dominance there is the option to set defaults that are widely 
>>> used. I think if certain defaults can bolster the security of Lightning 
>>> (and possibly other Layer 2 projects) at no cost to full node users with no 
>>> interest in those protocols we should discuss what those defaults should be.
>>>
>>> > 3.Are the recent improvements suggested for RBF policy only focused on 
>>> > Lightning Network and its security which will anyway remain same or 
>>> > become worse with multiple RBF policies?
>>>
>>> I think by nature of the Lightning Network being the most widely adopted 
>>> Layer 2 project most of the focus has been on Lightning security. But 
>>> contributors to other Layer 2 projects are free to flag and discuss 
>>> security considerations that aren't Lightning specific.
>>>
>>> > Note: Bitcoin Knots policy is fully configurable, even in the GUI - users 
>>> > can readily choose whatever policy *they* want.
>>>
>>> The maintainer(s) and contributors to Bitcoin Knots are free to determine 
>>> what default policy rules they want to implement (and make it easier for 
>>> users to change those defaults) in the absence of those policy rules being 
>>> made effective consensus rules. I suspect there would be strong opposition 
>>> to making some policy rules effective consensus rules but we are

Re: [Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via Lightning-dev]

free to determine 
> what default policy rules they want to implement (and make it easier for 
> users to change those defaults) in the absence of those policy rules being 
> made effective consensus rules. I suspect there would be strong opposition to 
> making some policy rules effective consensus rules but we are now venturing 
> again into future speculation and none of us have a crystal ball. Certainly 
> if you take the view that these policy rules should never be made effective 
> consensus rules then the fact there is at least one implementation taking a 
> contrasting approach to Core is a good thing.
>
> --
> Michael Folkson
> Email: michaelfolkson at > protonmail.com <http://protonmail.com/>> Keybase: 
> michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>
>
> --- Original Message ---
>  On Sunday, February 13th, 2022 at 6:09 AM, Prayank via Lightning-dev 
>  wrote:
>  
>
>> Hello World,
>>
>> There was a discussion about improving fee estimation in Bitcoin Core last 
>> year in which 'instagibbs' mentioned that we cannot consider mempool as an 
>> orderbook in which which everyone is bidding for block space because nodes 
>> can use different relay policies: 
>> https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;
>>
>> Although I still don't consider fee rates used in last few blocks relevant 
>> for fee estimation, it is possible that we have nodes with different relay 
>> policies.
>>
>> Similarly if we have different RBF policies being used by nodes in future, 
>> how would this affect the security of lightning network implementations and 
>> other layer 2 projects? 
>>
>> Based on the things shared by 'aj' in 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html
>>  it is possible for an attacker to use a different RBF policy with some 
>> nodes, 10% hash power and affect the security of different projects that 
>> rely on default RBF policy in latest Bitcoin Core.
>>
>> There was even a CVE in which RBF policy not being documented according to 
>> the implementation could affect the security of LN: 
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
>>
>> 1.Is Lightning Network and a few other layer 2 projects vulnerable to 
>> multiple RBF policies being used? 
>>
>> 2.With recent discussion to change things in default RBF policy used by 
>> Core, will we have multiple versions using different policies? Are users and 
>> especially miners incentivized to use different versions and policies? Do 
>> they have freedom to use different RBF policy?
>>
>> 3.Are the recent improvements suggested for RBF policy only focused on 
>> Lightning Network and its security which will anyway remain same or become 
>> worse with multiple RBF policies?
>>
>> Note: Bitcoin Knots policy is fully configurable, even in the GUI - users 
>> can readily choose whatever policy *they* want.
>>
>> -- 
>> Prayank
>>
>> A3B1 E430 2298 178F
>>___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

[Lightning-dev] Lightning and other layer 2 projects with multiple RBF policies

[Prayank via Lightning-dev]

Hello World,

There was a discussion about improving fee estimation in Bitcoin Core last year 
in which 'instagibbs' mentioned that we cannot consider mempool as an orderbook 
in which which everyone is bidding for block space because nodes can use 
different relay policies: 
https://bitcoin-irc.chaincode.com/bitcoin-core-dev/2021-09-22#706294;

Although I still don't consider fee rates used in last few blocks relevant for 
fee estimation, it is possible that we have nodes with different relay policies.

Similarly if we have different RBF policies being used by nodes in future, how 
would this affect the security of lightning network implementations and other 
layer 2 projects? 

Based on the things shared by 'aj' in 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019846.html
 it is possible for an attacker to use a different RBF policy with some nodes, 
10% hash power and affect the security of different projects that rely on 
default RBF policy in latest Bitcoin Core.

There was even a CVE in which RBF policy not being documented according to the 
implementation could affect the security of LN: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html

1.Is Lightning Network and a few other layer 2 projects vulnerable to multiple 
RBF policies being used? 

2.With recent discussion to change things in default RBF policy used by Core, 
will we have multiple versions using different policies? Are users and 
especially miners incentivized to use different versions and policies? Do they 
have freedom to use different RBF policy?

3.Are the recent improvements suggested for RBF policy only focused on 
Lightning Network and its security which will anyway remain same or become 
worse with multiple RBF policies?

Note: Bitcoin Knots policy is fully configurable, even in the GUI - users can 
readily choose whatever policy *they* want.

-- 
Prayank

A3B1 E430 2298 178F
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

[Prayank via Lightning-dev]

Can you share the email address to get approval or permission for this type of 
bitcoin transactions? i.e. opening and closing of LN channels or OP_RETURN. I 
will keep that in Cc next time.

I can write chess moves on a dollar bill and send to my friends but it does not 
solve any of the problems. Bitcoin's blockchain or ledger is for transactions. 
As long as a transaction is valid, standard and paying fees nobody should have 
issues with what is being achieved with the transaction.

Thanks

-- 
Prayank

A3B1 E430 2298 178F



Dec 4, 2021, 15:30 by willt...@live.com.au:

> The frivolous use of block space - ie. to increase the demand for block space 
> -  is not encouraged. Although it is possible you may write chess moves on a 
> wrap of dollar bills and send them to your friends, nowhere that I know of 
> has this been recorded in a ledger as a valid past time.
>
> KING JAMES HRMH 
> Great British Empire
>
> Regards,
> The Australian
> LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
> of Hougun Manor & Glencoe & British Empire
> MR. Damian A. James Williamson
> Wills
>
> et al.
>
>  
> Willtech
> www.willtech.com.au
> www.go-overt.com
> duigco.org DUIGCO API
> and other projects
>  
>
> m. 0487135719
> f. +61261470192
>
>
> This email does not constitute a general advice. Please disregard this email 
> if misdelivered.
>  
>
>
> From:>  bitcoin-dev  on behalf 
> of Prayank via bitcoin-dev 
>  
> Sent:>  Saturday, 4 December 2021 3:36 PM
>  > To:>  Lightning Dev 
>  > Cc:>  Bitcoin Dev 
>  > Subject:>  [bitcoin-dev] Pawn (chess piece) | Breaking bitcoin by playing 
> chess>  >  
> Hello World,
>
> Link with what, why and how: 
> https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc
>
> Two related things that I found: 
>
> 1.> Koala Studio tried chess on LN in 2019 but shutdown in August 2019
> 2.Etleneum still has chess but works differently
>
> Primary goal of this project can be different and focus on testing Bitcoin 
> transactions. Secondary goal is to have fun and contribute in increasing 
> demand for block space. Maybe an app for developers to play chess, friendly 
> competitions, learn and share new things. 
>
> If chess sounds boring it can be replaced with any 2 player game that works 
> for such setup and can be played with patience over few hours/days.
>
> Spam? Sorry zero fee transactions do not work anymore. In fact, nothing below 
> 1 sat/vbyte fee rate would work and all transactions will pay fees that are 
> required long term. OP_RETURN is used by many projects and excluded from UTXO 
> set. Let me know if something looks wrong. I won't be working on this as busy 
> with another project and recently started contributing in Wasabi.
>
>
> -- 
> Prayank
>
> A3B1 E430 2298 178F
>

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

[Lightning-dev] Pawn (chess piece) | Breaking bitcoin by playing chess

[Prayank via Lightning-dev]

Hello World,

Link with what, why and how: 
https://gist.github.com/prayank23/22763f48199ed106e59801be43ad4efc

Two related things that I found: 

1.Koala Studio tried chess on LN in 2019 but shutdown in August 2019
2.Etleneum still has chess but works differently

Primary goal of this project can be different and focus on testing Bitcoin 
transactions. Secondary goal is to have fun and contribute in increasing demand 
for block space. Maybe an app for developers to play chess, friendly 
competitions, learn and share new things. 

If chess sounds boring it can be replaced with any 2 player game that works for 
such setup and can be played with patience over few hours/days.

Spam? Sorry zero fee transactions do not work anymore. In fact, nothing below 1 
sat/vbyte fee rate would work and all transactions will pay fees that are 
required long term. OP_RETURN is used by many projects and excluded from UTXO 
set. Let me know if something looks wrong. I won't be working on this as busy 
with another project and recently started contributing in Wasabi.


-- 
Prayank

A3B1 E430 2298 178F
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Issue assets on lightning

[Prayank via Lightning-dev]

Good morning ZmnSCPxj,

> I heard before that the RGB colored coin project had plans to be compatible 
> with Lightning so that channels could be denominated in an issued asset.

RGB will address lot of things but I was wondering if such things should exist 
in LN implementations by default. Example: If we had two ways to issue assets 
LA1 and LA2, the user can issue asset using a command: lightning-cli -named 
issueassets -type=LA1 -number=1000

> Blockstream I believe has plans to include support for Liquid-issued assets 
> in C-Lightning somehow; C-Lightning already supports running on top of Liquid 
> instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin 
> for the channel asset type)

This is interesting.

> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

Still trying to understand this problem and possible solutions. Interesting 
email though (TIL), thanks for sharing the link. Found related things explained 
Suredbits blog as well.


-- 
Prayank

A3B1 E430 2298 178F



Oct 13, 2021, 09:29 by zmnsc...@protonmail.com:

> Good morning Prayank,
>
>> Hello everyone,
>>
>> I wanted to know few things related to asset issuance on lightning:
>>
>> 1.Is it possible to issue assets on LN right now? If yes, what's the process 
>> and is it as easy as few commands in liquid: 
>> https://help.blockstream.com/hc/en-us/articles/95127583-How-do-I-issue-an-asset-on-Liquid-
>>
>> 2.If no, is anyone working or planning to work on it?
>>
>> 3.I had read few things about Omni BOLT which could solve this problem but 
>> not sure about status of project and development: 
>> https://github.com/omnilaboratory/OmniBOLT-spec
>>
>> Few use cases for tokens on lightning:
>>
>> 1.DEX
>> 2.Stablecoins
>> 3.Liquidity: If projects could incentivize users with native tokens that are 
>> associated with the project on every LN channel opened it would improve 
>> liquidity.
>>
>
> I heard before that the RGB colored coin project had plans to be compatible 
> with Lightning so that channels could be denominated in an issued asset.
>
> Most plans for colored coins on Lightning generally assume that each channel 
> has just a single asset, as that seems to be simpler, at least as a start.
> However, this complicates the use of such channels for forwarding, as we 
> would like to restrict channel gossip to channels that *any* node can easily 
> prove actually exist as a UTXO onchain.
> Thus, colored coins would need to somehow be provable as existing to *any* 
> node (or at least those that support colored coins somehow) on the LN.
>
> Blockstream I believe has plans to include support for Liquid-issued assets 
> in C-Lightning somehow; C-Lightning already supports running on top of Liquid 
> instead of directly on the Bitcoin blockchain layer (but still uses Bitcoin 
> for the channel asset type).
>
> Generally, the assumption is that there would be a Lightning Network where 
> channels have different asset types, and you can forward via any channel, 
> suffering some kind of asset conversion fee if you have a hop where the 
> incoming asset is different from the outgoing asset.
>
>
> However, do note that some years ago I pointed out that swaps between two 
> *different* assets are a form of very lousy American Call Option: 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html
>
> Due to this, issued assets may not be usable on Lightning after all, even if 
> someone makes the work to make non-Bitcoin assets on Lightning channels.
>
> I am unaware of any actual decent solutions to the American Call Option 
> problem, but it has been a few years since then and someone might have come 
> up with a solution by now (we hope, maybe).
> I believe CJP had a trust-requiring solution: 
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001292.html
>  and https://bitonic.nl/public/slowdown_prevention.pdf
> Here is a paper which requires Ethereum (I have not read it because it 
> required Ethereum): https://eprint.iacr.org/2019/896.pdf
>
> It may be possible to use Barrier Escrows: 
> https://suredbits.com/payment-points-implementing-barrier-escrows/
> Barrier Escrows are still trusted (and I think they can serve as the RM role 
> in the CJP paper?) to operate correctly, but the exact use of their service 
> is blinded to them.
> Of course, any single participant of a multi-participant protocol can 
> probably unblind the Barrier Escrow, so still not a perfectly trustless 
> solution.
>
>
>
> Regards,
> ZmnSCPxj
>

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

[Lightning-dev] Issue assets on lightning

[Prayank via Lightning-dev]

Hello everyone,

I wanted to know few things related to asset issuance on lightning:

1.Is it possible to issue assets on LN right now? If yes, what's the process 
and is it as easy as few commands in liquid: 
https://help.blockstream.com/hc/en-us/articles/95127583-How-do-I-issue-an-asset-on-Liquid-

2.If no, is anyone working or planning to work on it?

3.I had read few things about Omni BOLT which could solve this problem but not 
sure about status of project and development: 
https://github.com/omnilaboratory/OmniBOLT-spec

Few use cases for tokens on lightning:

1.DEX2.Stablecoins3.Liquidity: If projects could incentivize users with native 
tokens that are associated with the project on every LN channel opened it would 
improve liquidity.


-- 
Prayank

A3B1 E430 2298 178F
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] v0.10.1: "eltoo: Ethereum Layer Too"

[Prayank via Lightning-dev]

> Though I'm sure they're open to new name suggestions for the next release if 
>you can think of one.

Few suggestions:

August: Hal Finney 
September: El Salvador
October: Silk Road
November: First Halving
December: 2228 (Last post: https://bitcointalk.org/index.php?topic=2228)

-- 
Prayank
 
A3B1 E430 2298 178F



Aug 12, 2021, 17:53 by michaelfolk...@gmail.com:

> Just a joke. Previous release names have been "Federal Qualitative
> Strengthening", "(Still) Scaling the Ethereum Blockchain", "Blockchain
> Good, Orange Coin Bad", "Bitcoin's Proof of Stake" etc
>
> https://github.com/ElementsProject/lightning/releases
>
> I can assure you the c-lightning team isn't planning to introduce
> proof of stake to Bitcoin or change its monetary policy. Though I'm
> sure they're open to new name suggestions for the next release if you
> can think of one.
>
> On Thu, Aug 12, 2021 at 4:15 AM Prayank via Lightning-dev
>  wrote:
>
>>
>> Hi Lisa,
>>
>> > lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
>>
>> > We're pleased to announce the 0.10.1 release of c-lightning
>> > <https://github.com/ElementsProject/lightning/releases/tag/v0.10.1>, named
>> > by @nalinbhardwaj.
>>
>> I am confused about the subject of this email. Is this an Ethereum project? 
>> What exactly is Ethereum layer and how is it related to this release?
>>
>> --
>> Prayank
>>
>> A3B1 E430 2298 178F
>>
>>
>>
>> ___
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
>
>
> -- 
> Michael Folkson
> Email: michaelfolk...@gmail.com
> Keybase: michaelfolkson
> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>

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

Re: [Lightning-dev] v0.10.1: "eltoo: Ethereum Layer Too"

[Prayank via Lightning-dev]

Hi Lisa,

> lisa neigut Mon, 09 Aug 2021 18:04:51 -0700
> We're pleased to announce the 0.10.1 release of c-lightning
> , named
> by @nalinbhardwaj.
I am confused about the subject of this email. Is this an Ethereum project? 
What exactly is Ethereum layer and how is it related to this release?

-- 
Prayank

A3B1 E430 2298 178F
 

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

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

[Prayank via Lightning-dev]

> As feerates have gone up over time, and as we expect them to go up further, 
>we should be considering drastically increasing the 3 sat/vByte basis to 
>something more like 20 sat/vB.

I have no opinion on changing or removing dust limit. However, fee rates are 
not going up. Yes, we expect them to go up and miners revenue from fees as 
well. Although, fees/day (in terms of BTC) has been decreasing in each cycle. 
Fee rates have been ranging between 1 sat/vByte to 200-300 sat/vByte, regularly 
reset to 1-5 sat/vByte and very low since long time now except when hash rate 
went down.

Fees per MB since 2016: https://i.imgur.com/XEkkf99.png 

Highest in this cycle on April 19 2021: 2.5 BTC
Highest in previous cycle on December 18 2017: 10 BTC

It stays low all the time except few days in each cycle.

-- 
Prayank
 
A3B1 E430 2298 178F

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