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

A better solution is to just have the sending wallet check to see if the address you are about to send to has been used before. If it's a fresh address, it sends it through without any popup alert. If the address has history going back a certain amount of time, then a popup comes up and notifies

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

> If there is a split, it becomes 2 incompatible ledgers. Not necessarily. When the BIP50 hard fork happened, it didn't create two incompatible ledgers. It *could* have, but it didn't. If every single transaction mined during that time has been "double spent" on the other chain, then it would

Re: [bitcoin-dev] Anti-transaction replay in a hardfork

I don't think the solution should be to "fix the replay attack", but rather to "force the replay effect". The fact that transactions can be relayed should be seen as a good thing, and not something that should be fixed, or even called an "attack". The solution should be to create a "bridge" that

Re: [bitcoin-dev] A BIP for partially-signed/not-signed raw transaction serialization; would it be useful?

I approve of this idea. Counterparty has the same problem. Their API returns a unsigned transaction that is formed differently from how other unsigned transactions, which causes friction. Someone needs to write up a specification that is standardized so that all unsigned transactions are of the

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

Its too bad you're not the one who decides what gets posted here or not. If you don't like whats being discussed, then don't open those emails. On 1/7/17, Eric Lombrozo via bitcoin-dev wrote: > Can you guys please take this discussion elsewhere? Perhaps to

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

ibery, coercion, and other tomfoolery as 75% of the > hashrate is ultimately only a dozen people or so. > > You have plenty of channels through which you can make your announcements, > this particular one is not okay. > > On Jan 7, 2017 3:12 PM, "Chris P

Re: [bitcoin-dev] Bitcoin Classic 1.2.0 released

Bitcoin Classic only activates if 75% of the network adopts it. That is not irresponsible or dangerous. It would only be dangerous if it activates at 50%, because that would create a situation where its not clear which side of the fork has the most proof of work. On 1/7/17, Eric Lombrozo via

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

.@voskuil.org> wrote: > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote: >> On 1/3/17, Jonas Schnelli via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >>> >>> There are plenty, more sane options. If you can't run your own full-

Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security

On 1/3/17, Jonas Schnelli via bitcoin-dev wrote: > > There are plenty, more sane options. If you can't run your own full-node > as a merchant (trivial), maybe co-use a wallet-service with centralized > verification (maybe use two of them), I guess Copay

Re: [bitcoin-dev] On-going work: Coin Selection Simulation

>From my experience working with coin selection algorithms, there are three "goals" to it: 1. Minimize cost 2. Maximize privacy 3. Minimize UTXO footprint You can build a coin selection algorithm that achieves 1 and 3, but will sacrifice 2. If you want coin selectin to maximize your privacy, it

Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection

How does your system prevent against insider attacks? How do you know the money is stolen by someone who compromised server #4, and not stolen by the person who set up server #4? It is my understanding these days most attacks are inside jobs. On 8/24/16, Peter Todd via bitcoin-dev

Re: [bitcoin-dev] BIP 151

On 6/30/16, Erik Aronesty via bitcoin-dev wrote: > > I would like to see a PGP-like "web of trust" proposal for both the > security of the bitcoin network itself /and/ (eventually) of things like > transmission of bitcoin addresses. > > Something where nodes

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

On 5/17/16, Eric Lombrozo via bitcoin-dev wrote: > Nice! > > We’ve been talking about doing this forever and it’s so desperately needed. > "So desperately needed"? How do you figure? The UTXO set is currently 1.5 GB. What kind of computer these days doesn't

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

Segwit requires work from exchanges, wallets and services in order for adoption to happen. This is because segwit changes the rules regarding the Transaction data structure. A blocksize increase does not change the Transaction rules at all. The blocksize increase is a change to the Block

Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes

Its mostly a problem for exchanges and miners. Those entities need to be on the network 100% of the time because they are using the network 100% of the time. A normal wallet user isn't taking payments every few minutes like the exchanges are. "Getting booted off the network" is not something to

[bitcoin-dev] "Hashpower liquidity" is more important than "mining centralization"

The term "mining centralization" is very common. It come up almost in every single discussion relating to bitcoin these days. Some people say "mining is already centralized" and other such things. I think this is a very bad term, and people should stop saying those things. Let me explain: Under

Re: [bitcoin-dev] Segregated witness softfork with moderate adoption has very small block size effect

By that same logic, any wallet that implemented P2SH is also voting for an increased block size, since P2SH results in smaller transactions, in the same way SW results in smaller transactions. On 12/19/15, Peter Todd via bitcoin-dev wrote: > On Sat, Dec 19,

Re: [bitcoin-dev] We need to fix the block withholding attack

Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoretical attack, as the ones with all the hashpower today are not engaging in this behavior. Even if someone who had a lot

Re: [bitcoin-dev] We need to fix the block withholding attack

On 12/19/15, Emin Gün Sirer wrote: > > Chris Priest is confusing these attacks with selfish mining, and further, > his characterization of selfish mining is incorrect. Selfish Mining is > guaranteed to yield profits for any pool over 33% (as a result, Nick > Szabo has dubbed

Re: [bitcoin-dev] We need to fix the block withholding attack

Then shouldn't this be something the pool deals with, not the bitcoin protocol? On 12/19/15, Matt Corallo <lf-li...@mattcorallo.com> wrote: > Peter was referring to pool-block-withholding, not selfish mining. > > On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev

Re: [bitcoin-dev] Forget dormant UTXOs without confiscating bitcoin

> In none of these cases do you lose anything. Nor do you gain anything. Archive nodes will still need to exist precisely because paper wallets don't include UTXO data. This is like adding the ability to partially seed a movie with bittorrent. You still need someone who has the whole thing has to

Re: [bitcoin-dev] BIP 9 style version bits for txns

I proposed in my Wildcard Inputs BIP that the version field be split in two. The first 4 bytes are version number (which in practice is being used for script version), and the second 4 bits are used for transaction type. I don't think the BIP9 mechanism really applies to transactions. A block is

Re: [bitcoin-dev] BIP 9 style version bits for txns

A wallet doesn't receive transactions from other wallets. That is what a node does. Wallets just make transactions and then sends them to the nodes. Nodes then send them to other nodes. In the early days of bitcoin, all wallets were nodes, but now a lot of wallets are just wallets with out any

[bitcoin-dev] Coalescing Transactions BIP Draft

I made a post a few days ago where I laid out a scheme for implementing "coalescing transactions" using a new opcode. I have since come to the realization that an opcode is not the best way to do this. A much better approach I think is a new "transaction type" field that is split off from the

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

al extra > mining fee for any transaction that used this opcode. > > Please be blunt about any of my own misunderstandings that this email makes > clear. > > On Tue, Nov 24, 2015 at 1:51 PM, Bryan Bishop via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> w

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

ay how > effective it would really be. > On 25 Nov 2015 12:48 a.m., "Chris Priest via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> > This idea could be applied by having the wildcard signature apply to >> > all >> > UT

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

y holder intended all inputs to be included. Hence the need for a new opcode. btw, this scheme is definitely in the 10x or higher gain. You could potentially spend an unlimited number of UTXOs this way. On 11/24/15, Gavin Andresen <gavinandre...@gmail.com> wrote: > On Tue, Nov 24, 201

[bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

Here is the problem I'm trying to solve with this idea: Lets say you create an address, publish the address on your blog, and tell all your readers to donate $0.05 to that address if they like your blog. Lets assume you receive 10,000 donations this way. This all adds up to $500. The problem is