Re: [bitcoin-dev] Fwd: Proposal of a new BIP : annual splitting blockchain database to reduce its size.

What makes this approach better than the prune option of Bitcoin? On Wed, Aug 16, 2017 at 10:20 AM, Алексей Мутовкин via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Let me describe the possible improvement of the bitcoin blockchain > database (BBD) size in general terms. > >

Re: [bitcoin-dev] Structure for Trustless Hybrid Bitcoin Wallets Using P2SH for Recovery Options

Colin, 1) This is a good start for a BIP, but it's missing details. For example, the nonce is encrypted by the server. What key is it encrypted with? Clarifying ambiguities like this can sometimes reveal weaknesses that you wouldn't otherwise think of. 2) What kind of recovery questions are

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

Two concerns: 1) This makes block validity depend on things that aren't in the blockchain. If you and I have different minrelaytxfee's, we will have different mempool sizes. Your node will discard a block, but my node will think it is valid, and our nodes will not come to consensus. 2) This is

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

Chain work currently means the expected number of sha256d evaluations needed to build a chain. Given that these hash functions are not equally hard, what should the new definition of chain work be? On Mon, Mar 20, 2017 at 9:38 AM, Andrew Johnson via bitcoin-dev <

Re: [bitcoin-dev] Flag day activation of segwit

>time >= 1506816000 && time <= 1510704000 && !IsWitnessEnabled() This has a different start time from the first post. >if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 ... Thanks, --Nick On Mon, Mar 13, 2017 at 4:36 AM, shaolinfry via bitcoin-dev <

Re: [bitcoin-dev] Flag day activation of segwit

The problem with modifying Bitcoin to work around community norms is that it's a two-way street. Other people can do it too. Let me propose a counter-fork, or a "Double UASF." This is also a BIP9 fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is 1506812400. It enforces

Re: [bitcoin-dev] Multisig with hashes instead of pubkeys

The first issue is that doing two OP_SWAP's in a row will just return you to the original state. The second issue is that all of them end up hashing the same key, so anyone on the network can spend this output. (See https://en.bitcoin.it/wiki/Script for a good resource on opcodes and what each of

Re: [bitcoin-dev] DPL is not only not enough, but brings unfounded confidence to Bitcoin users

Pledging to not use patents offensively defeats the point of owning patents. The point of owning a patent is so that you can use it offensively, either to prevent competition, or get licensing fees. Obtaining a patent for defense doesn't make sense. The litigants you need to worry about do not

Re: [bitcoin-dev] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY

Then you have a new problem. Hash1 must contain Hash2 and the transaction, but Hash2 must contain Hash1 and the transaction. A circular dependency. --Nick On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev wrote: > I hadn't thought of

Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin

Moral, Mining the sync flag isn't compatible with the payout structure of non hot-wallet pools like Eligius or decentralized pools like p2pool. Those need the ability to split a reward among multiple parties. Instead of giving an address to send the funds to, you could include the hash of the

Re: [bitcoin-dev] BIP 151

>They both require authentication, Yeah, but not the same *sort* of authentication. As a trivial example, you could have ten servers that sign long-term keys for nodes. All that they need to check is that the node requesting a signature owns the corresponding IP address. On the other hand, 'evil

Re: [bitcoin-dev] Making UTXO Set Growth Irrelevant With Low-Latency Delayed TXO Commitments

What if two people create transactions from oupoints within the same MMR tree tip, at the same time? For example, I create transaction A plus an MMR proof that MMR tip X will become Y. On the other side of the planet, someone else creates transaction B, plus an MMR proof that tip X will become

Re: [bitcoin-dev] An implementation of BIP102 as a softfork.

How are you collecting fees from the transactions in the block? On Sat, Jan 2, 2016 at 8:51 PM, joe2015--- via bitcoin-dev wrote: > On 2016-01-03 02:46, Marco Falke wrote: >> >> 2015-12-30 17:27 GMT+01:00 : >>> >>> On 2015-12-30