Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

On Dec 5, 2017 12:00 PM, "Sjors Provoost" wrote: ... I don't think all BIPs lend themselves to this pattern. Can you think of another example? Not right now, just seemed like a good idea to consider making it useful for more than one thing (maybe CT or something else could use it in the future

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

CryptAxe wrote: > Perhaps instead of a flag that can be used to disable a specific operation, > there should be a "-ignoredflags=x,y,z" section of the URI that can be used > to ignore whatever BIP this might also be useful for in the future? I don't think all BIPs lend themselves to this pattern

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

Perhaps instead of a flag that can be used to disable a specific operation, there should be a "-ignoredflags=x,y,z" section of the URI that can be used to ignore whatever BIP this might also be useful for in the future? On Dec 5, 2017 11:34 AM, "Sjors Provoost via bitcoin-dev" < bitcoin-dev@lists.

Re: [bitcoin-dev] Two Drivechain BIPs

Hi Other Chris, Thanks for pointing this out. Here are my responses. On 12/4/2017 3:11 PM, Chris Stewart wrote: >There is another interesting analysis on BMM and drivechains from /u/almkglor on reddit. I'm going to share here for visibility. >> 3 and 7 will mean that non-verifying miners will be

Re: [bitcoin-dev] BIP-21 amendment proposal: -no125

On Tuesday 05 December 2017 7:24:04 PM Sjors Provoost wrote: > I recently submitted a pull request that would turn on RBF by default, > which triggered some discussion [2]. To ease the transition for merchants > who are reluctant to see their customers use RBF, Matt Corallo suggested > that wallets

[bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks

# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks I admit, with my limited experience in the operation of the protocol, the section entitled 'Solution operation' may not be entirely correct but you will get the idea. If I have it wrong, please correct it back

Re: [bitcoin-dev] Two Drivechain BIPs

Hello, I would like to refer to these BIPs in other contexts and conversations. Regardless of the pitfalls or benefits, the discussion and technical review happening in this thread (and the ones before) are well-formed ideas with an active champion. The point of BIP numbers/conventions are so we'r

Re: [bitcoin-dev] Two Drivechain BIPs

>As far as I can tell there is no opportunity cost to casting a malicious vote, no repercussions, and no collective action barrier that needs to be overcome. There is another interesting analysis on BMM and drivechains from /u/almkglor on reddit

[bitcoin-dev] BIP-21 amendment proposal: -no125

One way to reduce fees is to encourage usage of Replace-By-Fee, BIP 125 [0]. It allows wallets to recommend lower fees, because if a transaction gets stuck due to underestimation, the fee can easily be bumped. Bitcoin Core has had support for RBF for a while, and as of v0.15.0 recommends lower

Re: [bitcoin-dev] Two Drivechain BIPs

Hello Chris, 1. Marginal Cost There actually is a very small cost to casting a malicious vote, relative to an honest vote. This is because the software (when run as-is), will automatically vote correctly. But to vote fraudulently you must decide on what to do instead, and configure that! This mig

[bitcoin-dev] Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication

I recently wrote this up for a client, and although the material has been covered elsewhere, I thought being a worked example it might be of interest, particularly while sidechains are being discussed again. As per (1) I've perhaps foolishly committed to making an even more fleshed out example, so