📝 Eudaimonios opened a pull request: "Create Implement Zero-Collar Options on Lightning Network for Stablec…"
(https://github.com/bitcoin/bitcoin/pull/30223)
…oin Value Stabilization and Volatility Reduction
Implement Zero-Collar Options on Lightning Network for Stablecoin Value Stabilization and Volatility Reduction
This pull request introduces a new feature that allows for the creation of zero-collar options on the Lightning Network to stabilize the value of stablecoins. The key components of this implementation are:
Zero-Collar Options: The ability to create options that are not dependent on the underlying asset's price, which can be used
...
(https://github.com/bitcoin/bitcoin/pull/30223)
…oin Value Stabilization and Volatility Reduction
Implement Zero-Collar Options on Lightning Network for Stablecoin Value Stabilization and Volatility Reduction
This pull request introduces a new feature that allows for the creation of zero-collar options on the Lightning Network to stabilize the value of stablecoins. The key components of this implementation are:
Zero-Collar Options: The ability to create options that are not dependent on the underlying asset's price, which can be used
...
💬 Eudaimonios commented on pull request "Create Implement Zero-Collar Options on Lightning Network for Stablec…":
(https://github.com/bitcoin/bitcoin/pull/30223#issuecomment-2147533551)
promising suggestion
(https://github.com/bitcoin/bitcoin/pull/30223#issuecomment-2147533551)
promising suggestion
✅ willcl-ark closed a pull request: "Create Implement Zero-Collar Options on Lightning Network for Stablec…"
(https://github.com/bitcoin/bitcoin/pull/30223)
(https://github.com/bitcoin/bitcoin/pull/30223)
💬 willcl-ark commented on pull request "Create Implement Zero-Collar Options on Lightning Network for Stablec…":
(https://github.com/bitcoin/bitcoin/pull/30223#issuecomment-2147540470)
I'm going to close for now as there's nothing to review here for now.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) or the #bitcoin IRC channel on the [Libera Chat](https://libera.chat/) network.
For proposed protocol changes you can post to the bitcoin-dev [mailing list](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) or [Delving Bitcoin](https://delvingbitcoin.org/).
For general b
...
(https://github.com/bitcoin/bitcoin/pull/30223#issuecomment-2147540470)
I'm going to close for now as there's nothing to review here for now.
General bitcoin questions and/or support requests are best directed to the [Bitcoin StackExchange](https://bitcoin.stackexchange.com/) or the #bitcoin IRC channel on the [Libera Chat](https://libera.chat/) network.
For proposed protocol changes you can post to the bitcoin-dev [mailing list](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev) or [Delving Bitcoin](https://delvingbitcoin.org/).
For general b
...
📝 fanquake locked a pull request: "Create Implement Zero-Collar Options on Lightning Network for Stablec…"
(https://github.com/bitcoin/bitcoin/pull/30223)
…oin Value Stabilization and Volatility Reduction
Implement Zero-Collar Options on Lightning Network for Stablecoin Value Stabilization and Volatility Reduction
This pull request introduces a new feature that allows for the creation of zero-collar options on the Lightning Network to stabilize the value of stablecoins. The key components of this implementation are:
Zero-Collar Options: The ability to create options that are not dependent on the underlying asset's price, which can be used
...
(https://github.com/bitcoin/bitcoin/pull/30223)
…oin Value Stabilization and Volatility Reduction
Implement Zero-Collar Options on Lightning Network for Stablecoin Value Stabilization and Volatility Reduction
This pull request introduces a new feature that allows for the creation of zero-collar options on the Lightning Network to stabilize the value of stablecoins. The key components of this implementation are:
Zero-Collar Options: The ability to create options that are not dependent on the underlying asset's price, which can be used
...
💬 hebasto commented on pull request "[DO NOT MERGE] cmake: Migrate CI scripts to CMake-based build system -- WIP":
(https://github.com/bitcoin/bitcoin/pull/29790#issuecomment-2147592508)
Rebased. Same as https://github.com/hebasto/bitcoin/pull/220.
(https://github.com/bitcoin/bitcoin/pull/29790#issuecomment-2147592508)
Rebased. Same as https://github.com/hebasto/bitcoin/pull/220.
🚀 fanquake merged a pull request: "fuzz: Make FuzzedSock fuzz friendlier"
(https://github.com/bitcoin/bitcoin/pull/30211)
(https://github.com/bitcoin/bitcoin/pull/30211)
💬 hebasto commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147687209)
After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147687209)
After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147694937)
> After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147694937)
> After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
💬 hebasto commented on pull request "[27.x] rc2 or final":
(https://github.com/bitcoin/bitcoin/pull/30222#issuecomment-2147698924)
> Backports:
>
> * [build: Fix building `fuzz` binary on on SunOS / illumos #30216](https://github.com/bitcoin/bitcoin/pull/30216)
>
> * [depends: Update Boost download link #30217](https://github.com/bitcoin/bitcoin/pull/30217)
>
>
> I don't think either of these changes warrants an `rc2` cycle.
Agree.
(https://github.com/bitcoin/bitcoin/pull/30222#issuecomment-2147698924)
> Backports:
>
> * [build: Fix building `fuzz` binary on on SunOS / illumos #30216](https://github.com/bitcoin/bitcoin/pull/30216)
>
> * [depends: Update Boost download link #30217](https://github.com/bitcoin/bitcoin/pull/30217)
>
>
> I don't think either of these changes warrants an `rc2` cycle.
Agree.
💬 hebasto commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147702543)
> > After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
>
> Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
This was what I tried before writing my comment :)
It doesn't work, unfortunately.
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147702543)
> > After conducting Guix builds, `lint_markdown` starts complaining about docs in `guix-build-*` subdirectories.
>
> Oh I didn't consider this directory! I think it should be possible to add `/guix-build-*` to the [ignored files](https://github.com/bitcoin/bitcoin/blob/d39f15a8a5b06d68070a3434a81c6840d4f87715/test/lint/test_runner/src/main.rs#L298).
This was what I tried before writing my comment :)
It doesn't work, unfortunately.
💬 willcl-ark commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147704039)
Ah, that is unfortunate. I will try and find another option...
(https://github.com/bitcoin/bitcoin/pull/30034#issuecomment-2147704039)
Ah, that is unfortunate. I will try and find another option...
💬 ryanofsky commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2147710137)
> Removing the blockman option looks like a nice improvement, but I am not sure yet about the renaming. Going from `do_reindex` to `wipe_block_tree_db` back to `m_reindexing` seems a bit convoluted.
That's a good point. One possible way to address it could be to rename `m_reindexing` as well like 38cc045b6966dda009332695ed55c86bd5a9fea3. If we move away from having multiple variables called "reindex" and instead name variables individually based on what they do, I think it would be an improve
...
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2147710137)
> Removing the blockman option looks like a nice improvement, but I am not sure yet about the renaming. Going from `do_reindex` to `wipe_block_tree_db` back to `m_reindexing` seems a bit convoluted.
That's a good point. One possible way to address it could be to rename `m_reindexing` as well like 38cc045b6966dda009332695ed55c86bd5a9fea3. If we move away from having multiple variables called "reindex" and instead name variables individually based on what they do, I think it would be an improve
...
💬 instagibbs commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626157391)
I like the comment in the VecDeque PR better if you'd care to just copy it here: https://github.com/bitcoin/bitcoin/pull/30161/commits/ecb278bb19c53b007380e262fa86d809255eeb49#diff-1f28310f089eac74210ecbc0db2083279282ade962dc464bd31448480dc5563dR59
(https://github.com/bitcoin/bitcoin/pull/30160#discussion_r1626157391)
I like the comment in the VecDeque PR better if you'd care to just copy it here: https://github.com/bitcoin/bitcoin/pull/30161/commits/ecb278bb19c53b007380e262fa86d809255eeb49#diff-1f28310f089eac74210ecbc0db2083279282ade962dc464bd31448480dc5563dR59
💬 hebasto commented on pull request "util: add BitSet":
(https://github.com/bitcoin/bitcoin/pull/30160#issuecomment-2147744433)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/30160#issuecomment-2147744433)
Concept ACK.
💬 ffrediani commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147764437)
Thanks @maflcko
The point perhaps it to find the proper way to implement this that doesn't cause trouble to these scenarios where a pruned node can be used and older stuff may almost never need to be accessed, and if so can be fetched as necessary.
I consider this is an issue given the very long time it takes to sync the whole blockchain, the amount of bandwidth wasted for something that could be simplified and improved greatly. This can also contribute to more adoption for people to run the
...
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147764437)
Thanks @maflcko
The point perhaps it to find the proper way to implement this that doesn't cause trouble to these scenarios where a pruned node can be used and older stuff may almost never need to be accessed, and if so can be fetched as necessary.
I consider this is an issue given the very long time it takes to sync the whole blockchain, the amount of bandwidth wasted for something that could be simplified and improved greatly. This can also contribute to more adoption for people to run the
...
💬 ffrediani commented on issue "Improve/simplify node sync for pruned nodes":
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147773585)
@maflcko please don't just close the issue because you think that should be discussed elsewhere you prefer and may not be interested in developing it. If this can be developed and there is a solution for it then that is the right place to be.
(https://github.com/bitcoin/bitcoin/issues/30220#issuecomment-2147773585)
@maflcko please don't just close the issue because you think that should be discussed elsewhere you prefer and may not be interested in developing it. If this can be developed and there is a solution for it then that is the right place to be.
⚠️ ffrediani opened an issue: "Improve/simplify node sync for pruned nodes"
(https://github.com/bitcoin/bitcoin/issues/30224)
### Please describe the feature you'd like to see added.
When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ? Can't it just download the amount of necessary and most recent data or a method developed for it and to speed up adoption of pruned nodes that will never keep all that amount of data ?
### Is your feature related to a problem, if so
...
(https://github.com/bitcoin/bitcoin/issues/30224)
### Please describe the feature you'd like to see added.
When running a pruned node it means it will keep only last X amount of GB predefined in the configuration, so why is it necessary to download the whole blockchain if only a tiny part will be kept at the end ? Can't it just download the amount of necessary and most recent data or a method developed for it and to speed up adoption of pruned nodes that will never keep all that amount of data ?
### Is your feature related to a problem, if so
...
💬 ismaelsadeeq commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626111198)
nit:
```suggestion
dummy_vbytes = (target_weight - tx.get_weight() + 3) // WITNESS_SCALE_FACTOR
```
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626111198)
nit:
```suggestion
dummy_vbytes = (target_weight - tx.get_weight() + 3) // WITNESS_SCALE_FACTOR
```
💬 ismaelsadeeq commented on pull request "test: MiniWallet: respect passed feerate for padded txs (using `target_weight`)":
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626172127)
In case of failure these lines wont be reached as we will fail early in `_bulk_tx`.
I think delegating the weight verification to `__bulk_tx` is more elegant, else It will be messy for all `create_self_transfer` callers to verify the tx weight and the target weight.
It will be cleaner to just delete this and move the debugging to `__bulk_tx`.
```suggestion
```
(https://github.com/bitcoin/bitcoin/pull/30162#discussion_r1626172127)
In case of failure these lines wont be reached as we will fail early in `_bulk_tx`.
I think delegating the weight verification to `__bulk_tx` is more elegant, else It will be messy for all `create_self_transfer` callers to verify the tx weight and the target weight.
It will be cleaner to just delete this and move the debugging to `__bulk_tx`.
```suggestion
```