Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

On Mon, Dec 21, 2015 at 4:33 AM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Dec 8, 2015 at 6:07 AM, Wladimir J. van der Laan wrote: > > On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via > bitcoin-dev wrote: > >> TL;DR: I propose we work

[bitcoin-dev] A new payment address format for segregated witness or not?

On the -dev IRC I asked the same question and people seem don't like it. I would like to further elaborate this topic and would like to consult merchants, exchanges, wallet devs, and users for their preference Background: People will be able to use segregated witness in 2 forms. They either

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

On Sun, Dec 20, 2015 at 11:35 AM, Peter Todd wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > > > On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia > wrote: > >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < >

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Remember this is proposed as an alternative to hardforks, which is also a > "nuclear option". Hardforks carry significant risks such as permanently > splitting Bitcoin into two chains

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On 2015-12-21 11:39, Jeff Garzik wrote: On Sun, Dec 20, 2015 at 12:21 PM, joe2015--- via bitcoin-dev wrote: Current hard fork implementations include / will include miner lock-in, just like any soft fork. They will not activate if global consensus is

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015/12/20 20:50, Mark Friedenbach via bitcoin-dev wrote: > I am fully in support of the plan laid out in "Capacity increases > for the bitcoin system". > > This plan provides real benefit to the ecosystem in solving a > number of longstanding

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

On 12/20/2015 3:34 AM, Jeff Garzik via bitcoin-dev wrote: > Ideally we should start having wallets generate those proofs now, and > then introduce the max-age as a second step as a planned hard fork a > couple years down the line. > > However, > 1) There is also the open question of

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On 2015-12-21 02:17, Bryan Bishop wrote: On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev wrote: An Arbitrary Block-size Increase Via a Generalized Softfork This seems conceptually similar to "extension blocks":

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

I am fully in support of the plan laid out in "Capacity increases for the bitcoin system". This plan provides real benefit to the ecosystem in solving a number of longstanding problems in bitcoin. It improves the scalability of bitcoin considerably. Furthermore it is time that we stop

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

There's quite a bit of confusion in this thread. Peter is referring to block withholding attacks. Ittay Eyal (as sole author -- I was not involved in this paper [1]) was the first to analyze these attacks and to discover a fascinating, paradoxical result. An attacker pool (A) can take a certain

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

On Sun, Dec 20, 2015 at 6:24 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What I proprosed is that a consensus-critical maximum UTXO age be part > of the protocol; UTXO's younger than that age are expected to be cached. > For UTXO's older than that age, they

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

On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > 2) This reverses the useful minimization attribute of HD wallets - "just backup the seed" It would be nice if the bip37 filter matching algorithm was extended to serve up the proof. And if

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On 2015-12-20 23:50, Tier Nolan via bitcoin-dev wrote: This is essentially the "nuclear option". Remember this is proposed as an alternative to hardforks, which is also a "nuclear option". Hardforks carry significant risks such as permanently splitting Bitcoin into two chains if global

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > An Arbitrary Block-size Increase Via a Generalized Softfork > This seems conceptually similar to "extension blocks":

Re: [bitcoin-dev] On the security of softforks

Jonathan Toomim via bitcoin-dev writes: > On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev > wrote: > >> 1) The risk of an old full node wallet accepting a transaction that is >> invalid to the new rules.

Re: [bitcoin-dev] On the security of softforks

Rusty Russell via bitcoin-dev 於 2015-12-19 23:14 寫到: Jonathan Toomim via bitcoin-dev writes: On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev wrote: 1) The risk of an old full node wallet accepting a

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

On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer < bitcoin-dev@lists.linuxfoundation.org> wrote: > An attacker pool (A) can take a certain portion of its hashpower, > use it to mine on behalf of victim pool (B), furnish partial proofs of work > to B, but discard any full blocks it discovers. > I

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

What will be the actual effect over wallets? Say I have the private key for a dormant UTXO older than the consensus-critical maximum UTXO age. The UTXO is not part of the cache. So I setup a full node and import my old private key (wallet.dat). Will I even see the correct balance (where will it

[bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

This is a draft. --joe Introduction It is generally assumed that increasing the blocksize limit requires a hardfork. Instead we show that a increasing the limit can be achieved using a "generalized" softfork. Like standard softforks, generalized softforks need a mere miner

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

On Sun, Dec 20, 2015 at 12:42 PM, Natanael wrote: > If total difficulty is X and the ratio for full blocks to candidate blocks > shared with the pool is Y, then the candidate block PoW now has to meet X/Y > while hashing the candidate block PoW + the pool's commitment hash

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

On Sun, Dec 20, 2015 at 12:12:49AM -0500, Emin Gün Sirer via bitcoin-dev wrote: > There's quite a bit of confusion in this thread. > > Peter is referring to block withholding attacks. Ittay Eyal (as sole > author -- I was not involved in this paper [1]) was the first Ah, thanks for the

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

Wouldn't block withhold be fixed by not letting miners in pools know which block candidates are valid before the pool knows? (Note: I haven't read any other proposals for how to fix it, this may already be known) As an example, by having the pool use the unique per-miner nonces sent to each miner

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

Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org>: > > On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer < bitcoin-dev@lists.linuxfoundation.org> wrote: >> >> An attacker pool (A) can take a certain portion of its hashpower, >> use it to mine on

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

Link to better formatted version for web-users: https://bitcointalk.org/index.php?topic=1296628.0 --joe ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 20 December 2015 08:30:45 GMT-08:00, Chris Pacia wrote: >On Dec 20, 2015 6:34 AM, "Jeff Garzik via bitcoin-dev" < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 2) This reverses the useful minimization attribute of HD

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

On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd wrote: > There are a number of techniques that can be used to detect block > withholding attacks that you are not aware of. These techniques usually > have the characteristic that if known they can be avoided, so obviously > those

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

This is essentially the "nuclear option". You are destroying the current chain (converting it to a chain of coinbases) and using the same POW to start the new chain. You are also giving everyone credit in the new chain equal to their credit in the old chain. It would be better if the current