Unfortunately this video format can current only played with nostr:nprofile1qqs24yz8xftq8kkdf7q5yzf4v7tn2ek78v0zp2y427mj3sa7f34ggjcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy2hwumn8ghj7un9d3shjtnwdaehgu3wvfnj7qgewaehxw309aex2mrp0yh8xmn0wf6zuum0vd5kzmp0f8mcfw .
Wonder when other clients ever will support this?
Example:
https://www.bitbubblex.com/uploads_qsa67WW2_Ju12_55gddG34/b9333fbbd68002c4ad7a4b6a58ee94a6.mp4
On most client only audio can be played.
This format is the default format of the Pixel 8 video recorder. Not found out how to change this.
https://www.bitbubblex.com/uploads_qsa67WW2_Ju12_55gddG34/dc01ff45dbe86e3f1f007a6c62334218.mp4
Need to tweak a bit with audio. Somehow it is not recorded well.
Thanks 👍🙏
Which nostr web client is also able to read encrypted messages made with nostr:npub142gywvjkq0dv6nupggyn2euhx4nduwc7yz5f24ah9rpmunr2s39se3xrj0 nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z
https://www.bitbubblex.com/uploads_qsa67WW2_Ju12_55gddG34/7d53e32b79576f1acd4df0e9e370b219.mp4
Ordinary evening at Cafe Babel in Valletta
It's already possible. Nobody including yourself cannot prove you are not an AI (bot). Maybe all of the conversations of today are AI already. Including my answer to you at this moment.....
nostr:note1hpd5s3snyv72fqqnpet2ef8cxgngatrewcdaswxetzrzguuqpg2qjstce9AutoZap? You mean the opposite of #HODL? More like #HFSP
Chatgpt on this: The phrase "Walking around aimlessly 🤷" is understandable in colloquial English, especially with the addition of the shrug emoji, which conveys a sense of uncertainty or indifference. However, if you're aiming for more formal or standard English, you might consider rephrasing it slightly:
"Wandering aimlessly."
The word "wandering" often carries the connotation of moving without a specific purpose or direction, which makes it a good fit for this context. Still, the phrase you provided is perfectly acceptable in many informal settings, and the emoji adds a playful or informal touch.
Meanwhile on X
Just realise when you want to buy stuff with the coins they force you to kyc source of funds. Except when there will be a time we can settle in btc of course. Patience is the key.
I have decide to stop with my lightning node.
Too risky.
Also got another force close of WalletOfSatoshi
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-October/022032.html
https://stacker.news/items/288995
I think this new class of replacement cycling attacks puts lightning in a
very perilous position, where only a sustainable fix can happen at the
base-layer, e.g adding a memory-intensive history of all-seen transactions
or some consensus upgrade. Deployed mitigations are worth something in face
of simple attacks, though I don't think they're stopping advanced attackers
as said in the first full disclosure mail.
Those types of changes are the ones necessitating the utmost transparency
and buy-in of the community as a whole, as we're altering the full-nodes
processing requirements or the security architecture of the decentralized
bitcoin ecosystem in its integrality.
On the other hand fully explaining why such changes would be warranted for
the sake of lightning and for designing them well, we might need to lay out
in complete state practical and critical attacks on a ~5 355 public BTC
ecosystem.
Hard dilemma.
There might be a lesson in terms of bitcoin protocol deployment, we might
have to get them right at first try. Little second chance to fix them in
flight.
I'll be silent on those issues on public mailing lists until the week of
the 30 oct. Enough material has been published and other experts are
available. Then I'll be back focusing more on bitcoin core.
Best,
Antoine
Another link found.
Multiple sources
I am not Antoine. No expert. And my node was to big for me to risk.
Let's wait and see what will revealed in the week of 30th October. I think there is more behind the scenes going on.
I had in fact. But still not sure what will revealed in the week of 30th of October
Quotation out of earlier posted link:
"I'll be silent on those issues on public mailing lists until the week of
the 30 oct. Enough material has been published and other experts are
available. Then I'll be back focusing more on bitcoin core.
Best,
Antoine"
Actually you can lose bitcoin:
Somewhere in the link:
A lightning node allows HTLCs forwarding (in bolt3's parlance accepted
> HTLC on incoming link and offered HTLC on outgoing link) should settle the
> outgoing state with either a success or timeout before the incoming state
> timelock becomes final and an asymmetric defavorable settlement might
> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"
> section 2.3 for a classical exposition of this lightning security property).
>
> Failure to satisfy this settlement requirement exposes a forwarding hop to
> a loss of fund risk where the offered HTLC is spent by the outgoing link
> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming
> link counterparty's HTLC-timeout.
>
> The specification mandates the incoming HTLC expiration timelock to be
> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC
> expiration timelock, this exact interval value being an implementation and
> node policy setting. As a minimal value, the specification recommends 34
> blocks of interval. If the timelock expiration I of the inbound HTLC is
> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC
> must be equal to 66 blocks from chain tip, giving a reasonable buffer of
> reaction to the lightning forwarding node.
>
> In the lack of cooperative off-chain settlement of the HTLC on the
> outgoing link negotiated with the counterparty (either
> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the
> lightning node should broadcast its commitment transaction. Once the
> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),
> the lightning node broadcasts and confirms its HTLC-timeout before I height
> is reached.
>
> Here enter a replacement cycling attack. A malicious channel counterparty
> can broadcast its HTLC-preimage transaction with a higher absolute fee and
> higher feerate than the honest HTLC-timeout of the victim lightning node
> and triggers a replacement. Both for legacy and anchor output channels, a
> HTLC-preimage on a counterparty commitment transaction is malleable, i.e
> additional inputs or outputs can be added. The HTLC-preimage spends an
> unconfirmed and unrelated to the channel parent transaction M and conflicts
> its child.
>
> As the HTLC-preimage spends an unconfirmed input that was already included
> in the unconfirmed and unrelated child transaction (rule 2), pays an
> absolute higher fee of at least the sum paid by the HTLC-timeout and child
> transaction (rule 3) and the HTLC-preimage feerate is greater than all
> directly conflicting transactions (rule 6), the replacement is accepted.
> The honest HTLC-timeout is evicted out of the mempool.
>
> In an ulterior move, the malicious counterparty can replace the parent
> transaction itself with another candidate N satisfying the replacement
> rules, triggering the eviction of the malicious HTLC-preimage from the
> mempool as it was a child of the parent T.
>
> There is no spending candidate of the offered HTLC output for the current
> block laying in network mempools.
>
> This replacement cycling tricks can be repeated for each rebroadcast
> attempt of the HTLC-timeout by the honest lightning node until expiration
> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout
> is broadcast by the counterparty's on the incoming link in collusion with
> the one on the outgoing link broadcasting its own HTLC-preimage.
>
> The honest Lightning node has been "double-spent" in its HTLC forwarding.
>
> As a notable factor impacting the success of the attack, a lightning
> node's honest HTLC-timeout might be included in the block template of the
> miner winning the block race and therefore realizes a spent of the offered
> output. In practice, a replacement cycling attack might over-connect to
> miners' mempools and public reachable nodes to succeed in a fast eviction
> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can
> come with a better ancestor-score, it should be picked up on the flight by
> economically competitive miners.
>
> A functional test exercising a simple replacement cycling of a HTLC
> transaction on bitcoin core mempool is available:
> https://github.com/ariard/bitcoin/commits/2023-test-mempool
>
> ## Deployed LN mitigations
>
> Aggressive rebroadcasting: As the replacement cycling attacker benefits
> from the HTLC-timeout being usually broadcast by lightning nodes only once
> every block, or less the replacement cycling malicious transactions paid
> only equal the sum of the absolute fees paid by the HTLC, adjusted with the
> replacement penalty. Rebroadcasting randomly and multiple times before the
> next block increases the absolute fee cost for the attacker.
>
> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .
>
> Local-mempool preimage monitoring: As the replacement cycling attacker in
> a simple setup broadcast the HTLC-preimage to all the network mempools, the
> honest lightning node is able to catch on the flight the unconfirmed
> HTLC-preimage, before its subsequent mempool replacement. The preimage can
> be extracted from the second-stage HTLC-preimage and used to fetch the
> off-chain inbound HTLC with a cooperative message or go on-chain with it to
> claim the accepted HTLC output.
>
> Implemented and deployed by Eclair and LND.
>
> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid
> by the attacker, a risk of the HTLC-preimage being detected or discovered
> by the honest lightning node, or the HTLC-timeout to slip in a winning
> block template. Bumping the default CLTV delta hardens the odds of success
> of a simple replacement cycling attack.
>
> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.
>
> ## Affected Bitcoin Protocols and Applications
