Nostr notes by

📅 Original date posted:2020-09-18 📝 Original ...

2023-06-07T20:26:53+02:00

In reply to nevent1q…8zvq
_________________________

📅 Original date posted:2020-09-18
📝 Original message:Conceptually this is so simple and explicit it almost seems like an obvious
primitive.

Glossing over some of the design/policy decisions...

I wonder what the real-world privacy implications are due to the
dependencies now being encoded on-chain rather than requiring some effort
to watch the mempool?

Cory

On Fri, Sep 18, 2020, 20:52 Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi Bitcoin Devs,
>
>
> I'd like to share with you a draft proposal for a mechanism to replace CPFP and RBF for
> increasing fees on transactions in the mempool that should be more robust against attacks.
>
> A reference implementation demonstrating these rules is available
> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx) for those who
> prefer to not read specs.
>
> Should the mailing list formatting be bungled, it is also available as a gist [here](https://gist.github.com/JeremyRubin/92a9fc4c6531817f66c2934282e71fdf).
>
> Non-Destructive TXID Dependencies for Fee Sponsoring
> ====================================================
>
> This BIP proposes a general purpose mechanism for expressing non-destructive (i.e., not requiring
> the spending of a coin) dependencies on specific transactions being in the same block that can be
> used to sponsor fees of remote transactions.
>
> Motivation
> ==========
>
> The mempool has a variety of protections and guards in place to ensure that miners are economic and
> to protect the network from denial of service.
>
> The rough surface of these policies has some unintended consequences for second layer protocol
> developers. Applications are either vulnerable to attacks (such as transaction pinning) or must go
> through great amounts of careful protocol engineering to guard against known mempool attacks.
>
> This is insufficient because if new attacks are found, there is limited ability to deploy fixes for
> them against deployed contract instances (such as open lightning channels). What is required is a
> fully abstracted primitive that requires no special structure from an underlying transaction in
> order to increase fees to confirm the transactions.
>
> Consensus Specification
> =======================
>
> If a transaction's last output's scripPubKey is of the form OP_VER followed by n*32 bytes, where
> n>1, it is interpreted as a vector of TXIDs (Sponsor Vector). The Sponsor Vector TXIDs must also be
> in the block the transaction is validated in, with no restriction on order or on specifying a TXID
> more than once. This can be accomplished simply with the following patch:
>
>
> ```diff
> +
> + // Extract all required fee dependencies
> + std::unordered_set<uint256, SaltedTxidHasher> dependencies;
> +
> + const bool dependencies_enabled = VersionBitsState(pindex->pprev, chainparams.GetConsensus(), Consensus::DeploymentPos::DEPLOYMENT_TXID_DEPENDENCY, versionbitscache) == ThresholdState::ACTIVE;
> + if (dependencies_enabled) {
> + for (const auto& tx : block.vtx) {
> + // dependency output is if the last output of a txn is OP_VER followed by a sequence of 32*n
> + // bytes
> + // vout.back() must exist because it is checked in CheckBlock
> + const CScript& dependencies_script = tx->vout.back().scriptPubKey;
> + // empty scripts are valid, so be sure we have at least one byte
> + if (dependencies_script.size() && dependencies_script[0] == OP_VER) {
> + const size_t size = dependencies_script.size() - 1;
> + if (size % 32 == 0 && size > 0) {
> + for (auto start = dependencies_script.begin() +1, stop = start + 32; start < dependencies_script.end(); start = stop, stop += 32) {
> + uint256 txid;
> + std::copy(start, stop, txid.begin());
> + dependencies.emplace(txid);
> + }
> + }
> + // No rules applied otherwise, open for future upgrades
> + }
> + }
> + if (dependencies.size() > block.vtx.size()) {
> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependencies-too-many-target-txid");
> + }
> + }
> +
> for (unsigned int i = 0; i < block.vtx.size(); i++)
> {
> const CTransaction &tx = *(block.vtx[i]);
> + if (!dependencies.empty()) {
> + dependencies.erase(tx.GetHash());
> + }
>
> nInputs += tx.vin.size();
>
> @@ -2190,6 +2308,9 @@ bool CChainState::ConnectBlock(const CBlock& block, BlockValidationState& state,
> }
> UpdateCoins(tx, view, i == 0 ? undoDummy : blockundo.vtxundo.back(), pindex->nHeight);
> }
> + if (!dependencies.empty()) {
> + return state.Invalid(BlockValidationResult::BLOCK_CONSENSUS, "bad-dependency-missing-target-txid");
> + }
> ```
>
> ### Design Motivation
> The final output of a transaction is an unambiguous location to attach metadata to a transaction
> such that the data is available for transaction validation. This data could be committed to anywhere,
> with added implementation complexity, or in the case of Taproot annexes, incompatibility with
> non-Taproot addresses (although this is not a concern for sponsoring a transaction that does not use
> Taproot).
>
> A bare scriptPubKey prefixed with OP_VER is defined to be invalid in any context, and is trivially
> provably unspendable and therefore pruneable.
>
> If there is another convenient place to put the TXID vector, that's fine too.
>
> As the output type is non-standard, unupgraded nodes will by default not include Transactions
> containing them in the mempool, limiting risk of an upgrade via this mechanism.
>
> Policy Specification
> ====================
>
> The mechanism proposed above is a general specification for inter-transaction dependencies.
>
> In this BIP, we only care to ensure a subset of behavior sufficient to replace CPFP and RBF for fee
> bumping.
>
> Thus we restrict the mempool policy such that:
>
> 1. No Transaction with a Sponsor Vector may have any child spends; and
> 1. No Transaction with a Sponsor Vector may have any unconfirmed parents; and
> 1. The Sponsor Vector must have exactly 1 entry; and
> 1. The Sponsor Vector's entry must be present in the mempool; and
> 1. Every Transaction may have exactly 1 sponsor in the mempool; except
> 1. Transactions with a Sponsor Vector may not be sponsored.
>
>
> The mempool treats ancestors and descendants limits as follows:
>
> 1. Sponsors are counted as children transactions for descendants; but
> 1. Sponsoring transactions are exempted from any limits saturated at the time of submission.
>
> This ensures that within a given package, every child transaction may have a sponsor, but that the
> mempool prefers to not accept new true children while there are parents that can be cleared.
>
> To prevent garbage sponsors, we also require that:
>
> 1. The Sponsor's feerate must be greater than the Sponsored's ancestor fee rate
>
> We allow one Sponsor to replace another subject to normal replacement policies, they are treated as
> conflicts.
>
>
> ### Design Motivation
>
> There are a few other ways to use OP_VER sponsors that are not included. For instance, one could
> make child chains that are only valid if their parent is in the same block (this is incompatible
> with CTV, exercise left to reader). These use cases are in a sense incidental to the motivation
> of this mechanism, and add a lot of implementation complexity.
>
> What is wanted is a minimal mechanism that allows arbitrary unconnected third parties to attach
> fees to an arbitrary transaction. The set of rules given tightly bounds how much extra work the
> mempool might have to do to account for the new sponsors in the worst case, while providing a "it
> always works" API for end users that is not subject to traditional issues around pinning.
>
> Eventually, rational miners may wish to permit multiple sponsor targets, or multiple sponsoring
> transactions, but they are not required for the mechanism to work. This is a benefit of the
> minimality of the consensus rule, it is compatible with future policy should it be implemented.
>
>
> #### Attack Analysis of new Policy
>
> In the worst case the new policy can lead to a 1/2 reduction in the number of children allowed
> (e.g., if there are 13 children submitted, then 12 sponsors, the 25 child limit will saturate
> before) and a 2x increase in the maximum children (e.g., if there are 25 children submitted, and
> then each are sponsored). Importantly, even in the latter attack scenario, the DoS surface is not
> great because the sponsor transactions have no children nor parents.
>
> #### Package Relay/Orphan Pool
>
> Future policy work might be able to insert sponsors into a special sponsor pool with an eviction
> policy that would enable sponsors to be queried and tracked for transactions that have too low fee
> to enter the mempool in the first place. This is treated as a separate concern, as any strides on
> package relay generally should be able to support sponsors trivially.
>
> Reference Implementation
> ========================
> A reference implementation demonstrating these rules is available
> [here](https://github.com/bitcoin/bitcoin/compare/master...JeremyRubin:subsidy-tx). This is a best
> effort implementation, but has not been carefully audited for correctness and likely diverges from
> this document in ways that should either be reflected in this document or amended in the code.
>
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>;
> <https://twitter.com/JeremyRubin>;
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200918/c7e52557/attachment-0001.html>;

📅 Original date posted:2019-06-20 📝 Original message:A ...

2023-06-07T20:18:39+02:00

In reply to nevent1q…qma4
_________________________

📅 Original date posted:2019-06-20
📝 Original message:A belated thanks (as always) for the great notes, Bryan. This is so
valuable!

Cory

On Fri, Jun 7, 2019 at 11:07 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> Hi,
>
> The following are some notes from the coredev.tech Amsterdam 2019 meeting.
> Any mistakes are my probably my own.
>
> Here is a conversation about the code review process in Bitcoin Core:
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-code-review/
>
> Here is a conversation with some of the maintainers about what problems
> they are seeing:
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-maintainers/
>
> Wallet re-architecture discussion
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-wallet-architecture/
>
> Great consensus cleanup
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-great-consensus-cleanup/
>
> SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY,
> OP_SECURETHEBAG
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/
>
> Taproot discussion
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-taproot/
>
> Utreexo
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-utreexo/
>
> assumeutxo
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-assumeutxo/
>
> Hardware wallets and HWI
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-hardware-wallets/
>
> bip151, p2p encryption and v2 message format
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-p2p-encryption/
>
> Signet for bitcoin test networks
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/
>
> Statechains overview
>
> http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/
>
> Thanks,
> - Bryan
> https://heybryan.org/
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190620/611c57f3/attachment.html>;

📅 Original date posted:2017-09-27 📝 Original message:Hi ...

2023-06-07T20:06:14+02:00

In reply to nevent1q…7gsa
_________________________

📅 Original date posted:2017-09-27
📝 Original message:Hi Mark

Thank you very much for posting the findings. I took a look through our
repository and I think I can provide a bit of context.

I'll go through each one, annotating what I've found.

> Apache License 2.0

This is used by a few java files in the libsecp256k1 project. That library
(which lives here: https://github.com/bitcoin-core/secp256k1) is a
sub-module created and maintained by Bitcoin Core developers. The files in
question are bindings that allow other applications to use libsecp256k1
from Java. Bitcoin Core makes no use of them.

> Boost Software License 1.0

This comes from tinyformat.h. Bitcoin Core indeed uses it.

> BSD 2-clause "Simplified" License

I'm unable to find any 2-clause BSD licensed files.

> BSD 3-clause "New" or "Revised" License

This comes from leveldb, which is database software used by Bitcoin Core.
Because database software version inconsistencies can cause accidental
forks (this actually happened in 2013), we include these files in our
repository and use them rather than linking to arbitrary versions at
runtime.

There are a few non-upstream files we use in our leveldb tree to provide
windows support. Quoting from src/leveldb/util/env_win.cc:
This file contains source that originates from:

http://code.google.com/p/leveldbwin/source/browse/trunk/win32_impl_src/env_win32.h

http://code.google.com/p/leveldbwin/source/browse/trunk/win32_impl_src/port_win32.cc
Those files don't have any explicit license headers but the
project (http://code.google.com/p/leveldbwin/) lists the 'New BSD License'

> Creative Commons Attribution Share Alike 3.0

I didn't manage to find any CC-licensed files. The match probably comes
from our gui svg icons, which contain an xml tag with a link to
creativecommons.org. This seems to be the default behavior of inkscape,
which was used to create those icons. Any icons that we have not created
ourselves are listed in contrib/debian/copyright (they're all expat/public
domain).

> Expat License

See MIT.

> GNU General Public License v2.0 or later

The debian folder, which holds the files used to create debian/ubuntu
packages is licensed gplv2+. These are packaging resources only,
unnecessary for use of the code.

Additionally, some gplv2 m4 macros are used to bootstrap the code that is
used to build the Bitcoin code. These contain the additional exception:

As a special exception, the respective Autoconf Macro's copyright owner
gives unlimited permission to copy, distribute and modify the configure
scripts that are the output of Autoconf when processing the Macro. You
need not follow the terms of the GNU General Public License when using
or distributing such scripts, even though portions of the text of the
Macro appear in them. The GNU General Public License (GPL) does govern
all other use of the material that constitutes the Autoconf Macro.

> GNU General Public License v3.0 or later

The macdeploy script, useful for creating DMG files for macOS is gplv3. It
is not necessary for any other platform, and is only used during the build
process. Additionally, it is not the only way to create DMG files (apple's
native tools can be used as well).

Additionally, config.guess and config.sub are gplv3 scripts used to build
our buildsystem.

> GNU Lesser General Public License v2.1 or later

authproxy.py, A python script used in our test suite is licensed lgpl
v2.1+. It is only necessary for running optional tests during development.

> License for A fast alternative to the modulo reduction

This references a comment cuckoocache.h. No code from the site is used. The
link to the site was added after the code, as the site provides a helpful
explanation for the technique used.

> License for atomic by Timm Kosse

Another m4 file. As explained with the others above, this is a macro which
builds code which builds code. It is used in the build process only.

> MIT License

The primary and default license for all contributions.

> Public Domain

> University of Illinois/NCSA Open Source License

clang-format-diff.py, a python script optionally used by developers to
clean up code changes.

tl;dr: Best I can tell, all source files that comprise Bitcoin Core
binaries are licensed (excluding the public domain ones) as MIT, BSD, or
Boost.

It's also worth repeating Omar's point that many of the files in the
Bitcoin Core repository are used for optional programs/libraries. None of
the artwork, for example, is needed for the primary bitcoin daemon.

Hope that helps!

Regards,
Cory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170927/af791133/attachment.html>;

📅 Original date posted:2016-02-01 📝 Original message:Thanks ...

2023-06-07T19:48:19+02:00

In reply to nevent1q…ym7k
_________________________

📅 Original date posted:2016-02-01
📝 Original message:Thanks for getting this started, Luke.

Noticeably absent here is the "default_witness_commitment" key, as
added by the current reference implementation[0].

I assume (please correct me if I'm wrong) that this has been omitted
for the sake of having clients create the commitment themselves as
opposed to having it provided to them.

I don't think that the two approaches (providing the default
commitment for the complete tx set as well as the ability to create it
from chosen transactions) are at odds with each-other, rather it
merely allows for a simpler approach for those who are taking tx's
as-is from bitcoind. It's obviously important for the clients to be
able to chose tx's and create commitments as they desire, but it's
equally important to allow for simpler use-cases.

The issue in particular here is that a non-trivial burden is thrust
upon mining software, increasing the odds of bugs in the process. I'd
like to point out that this is not a theoretical argument. I've
already fixed a handful of bugs relating to serialization or
commitment creation in the mining/pool software that I've worked on
for segwit [1][2][3][4]. Asking them to handle more serialization and
calculation of complex structures needlessly increases the complexity
for zero benefit in the case where the tx's are to be used as-is.

I'll PR this change to the BIP, as I can't really come up with an
argument against. At worst, it can simply be ignored.

[0]: https://github.com/sipa/bitcoin/blob/segwit/src/rpcmining.cpp#L590
[1]: https://github.com/bitcoin/libblkmaker/commit/22f6e42844aa14ed0037ebf12a734f07e63533d7
[2]: https://github.com/bitcoin/libblkmaker/commit/15e2c35bf69c997488e37147cf062dfa925b4912
[3]: https://github.com/bitcoin/libblkmaker/commit/9a5799891e0f3590779b8e5a993a7b306088e2fa
[4]: https://github.com/theuni/ckpool/commit/7d84b1d76b39591cc1c1ef495ebec513cb19a08e

Regards,
Cory

On Sat, Jan 30, 2016 at 1:50 PM, Luke Dashjr via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've completed an initial draft of a BIP for updating getblocktemplate for
> segregated witness here:
> https://github.com/luke-jr/bips/blob/segwit_gbt/bip-segwit-gbt.mediawiki
>
> Please review and comment (especially with regard to the changes in the
> sigoplimits handling).
>
> (Note: libblkmaker's reference implementation is at this time incompatible
> with the "last output" rule in this BIP.)
>
> Thanks,
>
> Luke
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-18 📝 Original message:See ...

2023-06-07T17:47:00+02:00

In reply to nevent1q…c2c5
_________________________

📅 Original date posted:2015-08-18
📝 Original message:See responses inline.

On Tue, Aug 18, 2015 at 6:31 AM, Tamas Blummer <tamas at bitsofproof.com> wrote:
> Thanks a lot Cory for following through the test case and producing a patch.
>
> I confirm that libconsensus is now running stable within the Bits of Proof
> stack,
> in-line with test cases we use to verify the java implementation of the
> script engine,
> that are BTW borrowed from Bitcoin Core.
>
> The performance of libconsensus is surprisingly close to the java one.
> Validating a 2-of-2 a multi-sig transaction runs at 1021 ops/sec with java
> and 1135 ops/sec
> in libconsensus. This is on a 2.2GH i7 laptop (4 hyper threading cores used
> by 8 threads).
> Another nice demonstration why one should not trade in advances
> of languages for the last decades for a marginal gain of performance with
> C/C++,
> I assume thereby that Bouncy Castle’ EC lib s not superior to OpenSSL's.

A few points there. First, Core is switching to libsecp256k1 for
several reasons, and one of them is speed. I seem to recall it being
up to 8x faster than OpenSSL.

Also, it can depend heavily on compiler switches and optimization
levels. For example, In playing with my test-case for hitting the
OpenSSL race issue, I managed to get a ~100% speedup by simply using
-O3 and lto.

>
> I disagree that the problem was rare in the real-world, it should affect any
> modern
> implementation that validates transactions parallel in multiple threads.
>

Well I'd say you're a bit biased in this case ;)

It's only those using ancient (0.98 or 1.00) versions of OpenSSL who
are affected, or those with OPENSSL_BN_ASM_MONT support disabled or
missing. Note that official releases of libbitcoinconsensus are
compiled against a much newer version and shouldn't have any issues.

The earlier patches for locking callbacks should be unnecessary.

> Aborting also does not make the problem less severe in my opinion.

Well it's not a good thing by any means, but it's certainly better
than incorrect results! In any undefined/error condition for the
consensus library, aborting is the right thing to do. If we can't
explain how we've reached a certain "unreachable" condition as is the
case here, the only reasonable recourse is to shut down. Otherwise we
risk network forks, DOS, etc.

> Therefore hope the pull will be included into Core with next release.
>

It will likely be unnecessary for the next release, but I do think
it's worth backporting to the 0.10 and 0.9 series.

> I can’t assign a timeline to “near future" secp256k1 integration. Can you?

I believe the libsecp256k1 guys are generally happy with the lib these
days, but I'll avoid guessing at a timeline. We can discuss that on
the PR for this fix, which I'll do today.

Regards,
Cory

📅 Original date posted:2015-08-18 📝 Original message:Back ...

2023-06-07T17:46:59+02:00

In reply to nevent1q…x04j
_________________________

📅 Original date posted:2015-08-18
📝 Original message:Back to the list (from github) in case anyone finds this via Google.

The patch that I posted here a few days ago did not fix the issue for Tamas.

I spent some time tracking down this edge-case because
libbitcoinconsensus needs to be as bullet-proof as possible. Thanks to
Tamas for creating a bare-bones test case after some discussion.

I finally managed to reproduce the issue on OSX. It's subtle and
likely rare in the real-world, though obviously not impossible given
the report here. For posterity, here's a rundown (braindump) of the
issue.

When calling EC_KEY_new_by_curve_name(), openssl internally checks to
see how to setup the curve's EC_METHOD (simple, montgomery, or nist).

Unfortunately, in all released OpenSSL versions (as far as I can tell
master is the only branch that has fixed this issue), it's tested like
so:

- Try a method. If it fails, set a global error and return.
- If the global error is set, try a different method.

Prior to OpenSSL 1.0.0, these were tested in the order:
EC_GFp_nist_method -> EC_GFp_mont_method. The secp256k1 curve fails
the ec_GFp_nist_group_set_curve test and sets the global error. That
error is then checked for failure, and EC_GFp_mont_method is tried
(and succeeds).

Obviously that global error usage is dangerous, especially since it
happens for _each_ transaction verification in libbitcoinconsensus. In
a multi-threaded environment, a crash is guaranteed within a few
seconds.

However, OpenSSL 1.0.1 reversed the order, trying EC_GFp_mont_method
first, so that the global error doesn't end up being used:
https://github.com/openssl/openssl/commit/17674bfdf75bffa4e225f8328b9d42cb74504005

This was backported from master back to 1.0.1, but not to 1.0.0 or 0.9.8.

So that change (accidentally) "solved" the problem. As you can see,
it's still possible to hit the reversed order in the
!defined(OPENSSL_BN_ASM_MONT) case. That's easily tested by building
OpenSSL with the -no-asm config option. It's probably also the case
for obscure architectures and OSs, but I haven't looked deeply into
that. In that case, it's reasonable to assume that this crash would
likely occur on such platforms.

Also, OSX, even the latest version (10.10 as of now), still ships with
OpenSSL 0.9.8. Which is how Tamas ran into it.

Since Bitcoin Core and libbitcoinconsensus are switching away from
OpenSSL for verification in the near future, I don't think this is
much of an issue. Especially since the problem manifests as a
controlled assertion failure/abort. However, I've prepared a patch for
anyone who may run into the issue in the short-term:
https://github.com/theuni/bitcoin/commit/adf0a691ee1c2f02e26828f976cfe5b78896b507

I'll open a pull-request for Bitcoin Core to discuss whether it's
worth merging or not.

Regards,
Cory

On Fri, Aug 14, 2015 at 5:10 PM, Cory Fields <lists at coryfields.com> wrote:
> Ugh, what an unfortunate oversight!
>
> The good news is that this issue should be solved in future versions
> when we switch to the new libsecp256k1 lib for validation.
>
> For now, I've thrown together a quick hack to allow a user-specifiable
> callback for libbitcoinconsensus. I think it's not worth messing with
> the official API since it will be fixed soon, but rather hacked in as
> a temporary work-around as needed. It _should_ be documented as an
> issue with the current version, though.
>
> Please see here for a work-around to try:
> https://github.com/theuni/bitcoin/commits/openssl-consensus-threads
> Unfortunately it's not pretty, but it works fine here. Note that you
> should give this some _serious_ testing before deploying in any real
> way. It should mimic the way we do it in Core, though.
>
> That's on top of current master, but it should be trivial to apply to
> release tags.
>
> Please let me know how it works out.
>
> Regards,
> Cory
>
> On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
>>
>> The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
>>
>> Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
>>
>> arises under that stress.
>>
>> I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
>> Registering those however would require access to OpenSSL functions, not exported from the lib.
>>
>> I’d be thankful for a pointer to a workaround.
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

📅 Original date posted:2015-08-14 📝 Original message:Ugh, ...

2023-06-07T17:46:59+02:00

In reply to nevent1q…324f
_________________________

📅 Original date posted:2015-08-14
📝 Original message:Ugh, what an unfortunate oversight!

The good news is that this issue should be solved in future versions
when we switch to the new libsecp256k1 lib for validation.

For now, I've thrown together a quick hack to allow a user-specifiable
callback for libbitcoinconsensus. I think it's not worth messing with
the official API since it will be fixed soon, but rather hacked in as
a temporary work-around as needed. It _should_ be documented as an
issue with the current version, though.

Please see here for a work-around to try:
https://github.com/theuni/bitcoin/commits/openssl-consensus-threads
Unfortunately it's not pretty, but it works fine here. Note that you
should give this some _serious_ testing before deploying in any real
way. It should mimic the way we do it in Core, though.

That's on top of current master, but it should be trivial to apply to
release tags.

Please let me know how it works out.

Regards,
Cory

On Fri, Aug 14, 2015 at 12:37 PM, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> We integrated libconsensus into bits of proof. It works well, in-line for all test cases with our Java engine and is about 50% faster on a single thread.
>
> The performance advantage unfortunatelly reverses if libconsensus is executed on several threads simultaneously as we do with the Java engine, since an error:
>
> Assertion failed: (pkey != NULL), function CECKey, file ecwrapper.cpp, line 96.
>
> arises under that stress.
>
> I guess that the cause is that thread callbacks as advised for OpenSSL on https://www.openssl.org/docs/crypto/threads.html are not registered.
> Registering those however would require access to OpenSSL functions, not exported from the lib.
>
> I’d be thankful for a pointer to a workaround.
>
> Tamas Blummer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-07-22 📝 Original message:On ...

2023-06-07T17:43:08+02:00

In reply to nevent1q…cj8t
_________________________

📅 Original date posted:2015-07-22
📝 Original message:On Wed, Jul 22, 2015 at 8:13 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
>> On Jul 22, 2015, at 5:05 PM, Cory Fields <lists at coryfields.com> wrote:
>>
>> On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>> FWIW, I had worked on something similar a while back:
>>> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>>>
>>> I like the idea in principle…but we should require a new genesis block,
>>> different magic bytes, and a different network port at the very least. :)
>>>
>>
>> Not sure if serious, so I'll assume you are :)
>
> Only being partly serious - I strongly am in favor of a sufficiently modularized codebase that swapping out consensus rules is fairly straightforward and easy to test. I’m not in favor of encouraging forking an existing blockchain without having mechanisms in place to gracefully merge back without significant network disruptions. We do not have this yet.
>

Again, why? If someone wants to create a scamcoin, they can. If
someone wants to burn money on a scamcoin, equally, they can. I'm not
sure how this is any different. If someone manages to garner realistic
support for a hard-fork, I don't see the benefit in forcing them to
use forked software.. that only leaves Core in the middle because it's
forced to choose a side (not choosing is unfortunately a side as
well). It doesn't remove the reality of the split.

>> Why? The idea in this case would be to allow the user to decide
>> between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
>> runtime rather than the likely alternative of "./bitcoind" vs
>> "./bitcoin-fork”.
>
> That’s exactly what my coinparams_new branch does. Adding a parameter for maximum block size would be straightforward.
>
>> Chain params may be identical other than the value of some future
>> event (miner vote for example), in which case the configs would run
>> identically until that point.
>
> Yes, indeed - this would be a special case.
>
>> If your concern is about nodes with different configs communicating
>> with eachother, I'd like to reiterate: the idea really is no different
>> than suggesting that someone fork the codebase and implement their own
>> changes, it just cuts out most of the work required.
>
> I do not encourage anyone to try to fork an existing blockchain without first securing overwhelming (near unanimous) consensus…or without having yet built a mechanism that can merge divergent chains gracefully.

Well of course. It would be a terrible idea. People would try it and
fail, and lose money. But for those crying foul at Core for being the
consensus/policy gatekeeper, it seems to me that user-selectable
params is the only logical solution.

📅 Original date posted:2015-07-22 📝 Original ...

2023-06-07T17:43:07+02:00

In reply to nevent1q…fnw7
_________________________

📅 Original date posted:2015-07-22
📝 Original message:I'm not sure why Bitcoin Core and the rules and policies that it
enforces are being conflated in this thread. There's nothing stopping
us from adding the ability for the user to decide what their consensus
parameters should be at runtime. In fact, that's already in use:
./bitcoind -testnet. As mentioned in another thread, the chain params
could even come from a config file that the user could edit without
touching the code.

I realize that it'd be opening Pandora's Box, and likely met with very
loud and reasonable arguments about the obvious terrible implications,
but it's at least an alternative to the current status quo of Core's
conflation with the consensus rules. The idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

With that in place, consensus changes would be more about lobbying and
coalitions, and less about pull requests.

Cory

On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> If the developers fail to reflect user consensus, the network will let us
>> know.
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference. If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I wouldn't go quite that far. The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>> Upgrading to a version of Bitcoin Core that is incompatible with your
>> ideals is in no way a forced choice, as you have stated in your email;
>> forks, alternative clients, or staying on an older version are all valid
>> choices. If the majority of the network chooses not to endorse a specific
>> change, then the majority of the network will continue to operate just fine
>> without it, and properly structured consensus rules will pull the minority
>> along as well.
>
> The developers propose a new version, by publishing a new release. The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work. Consensus is most
> strongly measured by user actions after software release. If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-07-22 📝 Original message:On ...

2023-06-07T17:43:07+02:00

In reply to nevent1q…4cz2
_________________________

📅 Original date posted:2015-07-22
📝 Original message:On Wed, Jul 22, 2015 at 7:53 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> FWIW, I had worked on something similar a while back:
> https://github.com/CodeShark/bitcoin/tree/coinparams_new/altconf
>
> I like the idea in principle…but we should require a new genesis block,
> different magic bytes, and a different network port at the very least. :)
>

Not sure if serious, so I'll assume you are :)

Why? The idea in this case would be to allow the user to decide
between (say) "./bitcoind -1mbchain" and "./bitcoind -2mbchain" at
runtime rather than the likely alternative of "./bitcoind" vs
"./bitcoin-fork".

Chain params may be identical other than the value of some future
event (miner vote for example), in which case the configs would run
identically until that point.

If your concern is about nodes with different configs communicating
with eachother, I'd like to reiterate: the idea really is no different
than suggesting that someone fork the codebase and implement their own
changes, it just cuts out most of the work required.

Cory

> On Jul 22, 2015, at 4:42 PM, Cory Fields via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I'm not sure why Bitcoin Core and the rules and policies that it
> enforces are being conflated in this thread. There's nothing stopping
> us from adding the ability for the user to decide what their consensus
> parameters should be at runtime. In fact, that's already in use:
> ./bitcoind -testnet. As mentioned in another thread, the chain params
> could even come from a config file that the user could edit without
> touching the code.
>
> I realize that it'd be opening Pandora's Box, and likely met with very
> loud and reasonable arguments about the obvious terrible implications,
> but it's at least an alternative to the current status quo of Core's
> conflation with the consensus rules. The idea really is no different
> than suggesting that someone fork the codebase and implement their own
> changes, it just cuts out most of the work required.
>
> With that in place, consensus changes would be more about lobbying and
> coalitions, and less about pull requests.
>
> Cory
>
> On Wed, Jul 22, 2015 at 6:40 PM, Raystonn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If the developers fail to reflect user consensus, the network will let us
> know.
>
>
> This is true with the caveat that there must be more than one option present
> for the network to show it's preference. If developers discourage anything
> that forks from the rules enforced by Bitcoin Core, they harm the network's
> ability to inform us of a failure to reflect user consensus.
>
> On 22 Jul 2015 3:31 pm, Jeff Garzik via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I wouldn't go quite that far. The reality is somewhere in the middle, as
> Bryan Cheng noted in this thread:
>
> Quoting BC,
>
> Upgrading to a version of Bitcoin Core that is incompatible with your
> ideals is in no way a forced choice, as you have stated in your email;
> forks, alternative clients, or staying on an older version are all valid
> choices. If the majority of the network chooses not to endorse a specific
> change, then the majority of the network will continue to operate just fine
> without it, and properly structured consensus rules will pull the minority
> along as well.
>
>
> The developers propose a new version, by publishing a new release. The
> individual network nodes choose to accept or reject that.
>
> So I respectfully disagree with "core devs don't control the network" and
> "core devs control the network" both.
>
> There are checks-and-balances that make the system work. Consensus is most
> strongly measured by user actions after software release. If the developers
> fail to reflect user consensus, the network will let us know.
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Jul 22, 2015 at 2:43 PM, Mike Hearn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi Pieter,
>
> I think a core area of disagreement is this:
>
> Bitcoin Core is not running the Bitcoin economy, and its developers have no
> authority to set its rules.
>
> In fact Bitcoin Core is running the Bitcoin economy, and its developers do
> have the authority to set its rules. This is enforced by the reality of
> ~100% market share and limited github commit access.
>
> You may not like this situation, but it is what it is. By refusing to make a
> release with different rules, people who disagree are faced with only two
> options:
>
> 1. Swallow it even if they hate it
> 2. Fork the project and fork the block chain with it (XT)
>
> There are no alternatives. People who object to (2) are inherently
> suggesting (1) is the only acceptable path, which not surprisingly, makes a
> lot of people very angry.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2014-10-15 📝 Original message:Sounds ...

2023-06-07T17:26:29+02:00

In reply to nevent1q…3k8w
_________________________

📅 Original date posted:2014-10-15
📝 Original message:Sounds like this is what you're after, it's a fairly new feature:
https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments

I've been meaning to use it in a PR to try it out.

Cory

On Wed, Oct 15, 2014 at 5:36 AM, Wladimir <laanwj at gmail.com> wrote:
>> This all makes a lot of sense to me, and would help a lot with the
>> workflow. Unfortunately github pulls and issues really have nothing
>> to faciltate a multistage workflow... e.g. where something can go
>> through several steps.
>
> Indeed, pull requests don't have a "status".
> It would be possible to (ab)use labels for this.
>
> The drawback of labels is that only the repository team can set these,
> there is no way to delegate. But I suppose it'd be possible to build
> something on top of the github API that handles this.
>
>> We're also having problems with people failing to comment on things,
>> not even "I looked at this and have no opinion", which is really
>> obstructing things.
>
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development