Re: [bitcoin-dev] [bitcoin-discuss] Proposal to replace full blockchain with recent history plus UTXO Set

Feel free to take a look at my implementation of UTXO loading (for core ~0.16.99) here: https://github.com/DriveNetTESTDRIVE/DriveNet/commit/60189ea9a23865180e25207ecf66f95d84f642c6 Note that this has consensus implications, and that there are bugs (some of which are fixed in later commits to

Re: [bitcoin-dev] Claiming an OP_RETURN Prefix

Don't worry about claiming it. There are no reserved prefixes enforced by the software. For example anyone could create an output that uses the witness coinbase commitment prefix bytes. It would just be ignored (unless it was in the coinbase, in which case it would also need to be valid). On Sun,

Re: [bitcoin-dev] Possible change to the MIT license

This is ridiculous. We shouldn't bastardize open source principals because someone hurt your feelings. This is how open source works, stop using it if you don't like it. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org

Re: [bitcoin-dev] Suggestion to remove word from BIP39 English wordlist

Why wouldn't they just test the frequency of words from the wordlist in entirety? On Jan 17, 2018 5:10 PM, "Weiwu Zhang via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 2018-01-09 19:20 GMT+08:00 Ronald van der Meer via bitcoin-dev > : > >

Re: [bitcoin-dev] Two Drivechain BIPs

On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote: > ... > This vulnerability can be fixed if withdrawals are restricted to > simple P2PKH or P2WPKH only, Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there be any network benefit to supporting witness pubkeys for

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

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" <

Re: [bitcoin-dev] Bitcoin Cash's new difficulty algorithm

Is there an issue with the current difficulty adjustment algorithm? It's worked very well as far as I can tell. Introducing a new one seems pretty risky, what would the benefit be? On Nov 2, 2017 4:34 PM, "Scott Roberts via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Bitcoin

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

You could technically call myself and Chris 'core developers'. You don't get to have a fixed rate of Bitcoin and a second way to mint coins at the same time. On Oct 10, 2017 1:46 PM, "Tao Effect via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > What? > > That is not correct. > >

Re: [bitcoin-dev] Generalized sharding protocol for decentralized scaling without Miners owning our BTC

Your method would change the number of Bitcoins in existence. Why? On Oct 10, 2017 12:47 PM, "Tao Effect via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Is that what passes for a technical argument these days? Sheesh. > > Whereas in Drivechain users are forced to give up their

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

I do agree with you to a degree, but address reuse is actually not even supposed to work (it is a bug). Peter Todd is suggesting only to make expiration a part of a new address format, and we could have a GUI warning (but no protocol change) for the existing formats. What do you think about that?

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

See https://github.com/bitcoin/bitcoin/pull/9722 What still needs to be done is that during the first start up after updating with this popup, the wallet needs to scan for addresses that have been used in the past. That way the popup isn't only shown for addresses that are reused after updating.

Re: [bitcoin-dev] Address expiration times should be added to BIP-173

I think we need something like this. Hour resolution seems like the correct choice to me. Please someone steal whatever code you can from this PR when implementing the UI for BIP173 expiration: https://github.com/bitcoin/bitcoin/pull/9722 I have a rebased version as well if anyone wants it.

Re: [bitcoin-dev] idea post: bitcoin side chain implementation

Have you taken a look at Elements or Drivechains yet by chance? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Responsible disclosure of bugs

I don't think we should put any Bitcoin users at additional risk to help altcoins. If they fork the code they are making maintenance their own responsibly. It's hard to disclose a bitcoin vulnerability considering the network is decentralised and core can't force everyone to update. Maybe a

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

obvious, someone point out why this is stupid please :) On 09/06/2017 06:29 PM, Adam Back wrote: > The pattern used by Felix Weiss' BIP for Confidential Transactions > depends on or is tidier with 0-value outputs. > > Adam > > > On 7 September 2017 at 00:54, CryptAxe via bitcoin-

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

As long as an unspendable outputs (OP_RETURN outputs for example) with amount=0 are still allowed I don't see it being an issue for anything. On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > This is not a priority, not very important either.

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

In case anyone wants to do this, I added the CSidechainAddress class to the mainchainBMM branch of the Drivechain project a long time ago. The only purpose it serves right now is to show that sidechain deposit addresses can start with a '4'. We could simply add the sha256 hash described by Paul to

Re: [bitcoin-dev] Updating the Scaling Roadmap

; > > -- > Please do not email me anything that you are not comfortable also > sharing with the NSA. > >> On Jul 12, 2017, at 12:54 PM, CryptAxe via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org >> <mailto:bitcoin-dev@lists.linuxfoundation.org&g

Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains

To ZmnSCPxj: I don't understand this part. In my scheme, a sidechain cannot reorganize unless the mainchain reorganizes, since the consensus loop only cares about matching the current block; it ignores splits and does not consider them valid. But I suppose you are considering something like the

Re: [bitcoin-dev] Drivechain -- Request for Discussion

> >OP_RETURN > > I think it is redundant here to have the , we can > implicitly assume what the sidechain_id is since we have a fixed set > of drivechains. I.e. mining reward is index 0, mimblewimble sidechain > is index 1, etc. CryptAxe has specific indexes defined already in his >

Re: [bitcoin-dev] Drivechain -- Request for Discussion

Your assumptions of the bribe process are indeed correct you seem to have a pretty good handle on all of that. Hopefully I can clear up a few things. BMM among other things is still a work in progress so you'll have to wait a bit longer before any reorg code is on github. The "ratchet" system on