Re: [bitcoin-dev] How much is too much time between difficulty changes?
It's possible to let the difficulty linearly drop as the solvetime goes beyond some limit (credit AS). If the limit is greater than any delay in the past it could be backwards-compatible. A simple daily-rolling average DA like BCH is probably the best option if a faster DA is ever needed. As a point of research interest (not likely to be needed by BTC), I've taken the first above idea of "intra-block" timestamp-based difficulty adjustment to the limit and made it symmetrical (higher D for fast solves) and continuous. The result is a "tightening of the Poisson" that increases "availability" (predictable solution times) at an expense in "consistency" (orphans). It requires a very tight future time limit to reduce timestamp manipulation. My objective was to help small coins deal with persistent 20x hash rate changes that result in long delays. About 3 coins have it on testnet. https://github.com/zawy12/difficulty-algorithms/issues/36 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] call for demos: Cryptocurrency Implementers' Workshop
Hi all, I'm happy to announce the first Cryptocurrency Implementers' Workshop, cohosted with Financial Crypto. http://fc19.ifca.ai/ciw/ Now that the BITCOIN cryptocurrency research workshop has been folded into the main FC conference, it's time to try something new. The goal of this workshop is to focus on real world experience and engineering efforts. As such we're soliciting submission of *running code* to give a live demo at the workshop. Because of the tight timeline, there are only two weeks to go before the submission deadline, Dec 21. More details below the fold, and at the website link. -- Andrew Miller University of Illinois at Urbana-Champaign With the inclusion of the BITCOIN: Bitcoin and Cryptocurrency Research Workshop into the "Blockchain Track" of the Financial Cryptography conference, we now want to try out an experimental new workshop format, which focuses on engineering, development, and real world use of cryptocurrencies and permissionless blockchains. In this first iteration, the workshop will be a half day, and the program will consist of two main components: Invited talks on implementation post mortems: - we will aim to have several talks from developers and engineers that have led and maintained open source software projects in use by cryptocurrencies today. Artifact Evaluation and Demo show and tell: We will have a technical program of demo presentations about open source software artifacts. Presenters must submit their talk and demo abstract along with the open source software itself for review. Presentation abstracts should be no more than 6 pages in LNCS format, or the equivalent length (no more than 2000 words) of text, Markdown, etc. The write up should include: motivation and application, novelty or differences compared to alternative or related implementations, challenges faced, possible evaluation approaches Submissions must include a software artifact that can be reviewed. It is expected the review committee will at least be able to run the artifact and observe the outputs. We recommend including a virtual machine image or Docker-based build instructions to facilitate this. Suggested topics The following list is non-exhaustive: Cryptography implementations, such as digital signatures, ring signatures, zero knowledge proofs Proof-of-work consensus protocols Proof-of-stake consensus protocols Mining hardware designs Peer-to-peer networking and broadcast relay code Full node synchronization SPV and lightweight clients Wallets and key management Security vulnerabilities and defenses Mining pools Mining rig controllers Staking wallets Important Dates Dec 21: Submission deadline Jan 7: Presenter notification Feb 22: Workshop Submission Instructions === The submission website and instructions will be available mid December. Demos accepted to this program will not be included in any proceedings. Submission and acceptance in this workshop does not preclude publication elsewhere. Submissions may be anonymized at the authors' discretion, but it is not a requirement. Program Commitee J. Ayo Akinyele (Yeletech) Rebekah Mercer (Aarhus) Pieter Wuille (Blockstream) Benedikt Bünz (Stanford) Ethan Heilman (Boston University, Commonwealth Crypto) Patrick McCorry (Kings College London) Justin Ehrenhofer (Monero Community WorkGroup) Jacob Eberhardt (tu-berlin) ... (more to come) Program Chairs Andrew Miller (UIUC) Christopher Allen Contact email address: Andrew Miller ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev wrote: > One more item to consider is "signature covers witness weight". > > While signing the witness weight doesn't completely eliminate witness > malleability (of the kind that can cause grief for compact blocks), it does > eliminate the worst kind of witness malleability from the user's > perspective, the kind where malicious relay nodes increase the amount of > witness data and therefore reduce the overall fee-rate of the transaction. To what degree is this an actual problem? If the mutated transaction pays a feerate at least incremental-relay-fee[1] below the original transaction, then the original transaction can be rebroadcast as an RBF replacement of the mutated transaction (unless the mutated version has been pinned[2]). -Dave [1] $ bitcoind -help-debug | grep -A2 incremental -incrementalrelayfee= Fee rate (in BTC/kB) used to define cost of relay, used for mempool limiting and BIP 125 replacement. (default: 0.1) [2] https://bitcoin.stackexchange.com/questions/80803/what-is-meant-by-transaction-pinning signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
The current proposal is that a 64-byte signature will be used for the default “signing all” sighash, and 65-byte for other sighash types. The space saved will allow a few more txs in a block, so I think it worths doing. However, this also makes witness weight estimation more difficult in multisig cases. This idea of signing witness weight has been brought up before. I think the concern is the difficulty to estimate the witness weight for complex scripts, which need this feature most. So it will work when it is not needed, and will not work when it is needed. Is there any script example that witness size malleability is unavoidable? > On 7 Dec 2018, at 12:57 AM, Russell O'Connor via bitcoin-dev > wrote: > > One more item to consider is "signature covers witness weight". > > While signing the witness weight doesn't completely eliminate witness > malleability (of the kind that can cause grief for compact blocks), it does > eliminate the worst kind of witness malleability from the user's perspective, > the kind where malicious relay nodes increase the amount of witness data and > therefore reduce the overall fee-rate of the transaction. Generally users > should strive to construct their Bitcoin Scripts in such a way that witness > malleability isn't possible, but as you are probably aware, this can be quite > difficult to achieve as Scripts become more complex and maybe isn't even > possible for some complex Scripts. > > Given the new fixed-sized signature of the Schnorr BIP, it becomes much > easier to compute the final witness weight prior to signing. In complex > multi-party signing protocol, the final witness weight might not be known at > signing time for everyone involved, so the "signature covers witness weight" > ought to be optional. > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
