On 2016-01-05 09:26, joe2015--- via bitcoin-dev wrote:
On 2016-01-05 02:04, Nick ODell wrote:
How are you collecting fees from the transactions in the block?
Probably the simplest way to do this is to map the new-rules coinbase
tx (which collects the block reward and fees) into an old-rules
On 2016-01-05 02:04, Nick ODell wrote:
How are you collecting fees from the transactions in the block?
Probably the simplest way to do this is to map the new-rules coinbase tx
(which collects the block reward and fees) into an old-rules legacy
coinbase tx (which collects the block reward only
On 2016-01-03 02:46, Marco Falke wrote:
2015-12-30 17:27 GMT+01:00 :
On 2015-12-30 18:33, Marco Falke wrote:
This is an interesting approach but I don't see how this is a soft
fork. (Just because something is not a hard fork, doesn't make it a
soft fork by definition)
Softforks don't require
On 2015-12-31 18:39, David Chan wrote:
The UTXO sets may diverge but they actually will be strict
subsets/supersets of each other as no transaction would be invalid on
one fork vs another unless the hard fork lasts longer than 100 blocks.
The UTXO sets can also diverge thanks to double spends,
So I'm very strongly against this "generalized softfork" idea -- I also
don't
see how upgraded nodes and non-upgraded nodes can possibly end up with
the same
UTXO set.
The only way for non-upgraded nodes to get the correct UTXO set is to
upgrade.
It is important to keep in mind this was pro
On 2015-12-30 18:33, Marco Falke wrote:
This is an interesting approach but I don't see how this is a soft
fork. (Just because something is not a hard fork, doesn't make it a
soft fork by definition)
Softforks don't require any nodes to upgrade. [1]
Nonetheless, as I understand your approach, it
Below is a proof-of-concept implementation of BIP102 as a softfork:
https://github.com/ZoomT/bitcoin/tree/2015_2mb_blocksize
https://github.com/jgarzik/bitcoin/compare/2015_2mb_blocksize...ZoomT:2015_2mb_blocksize?diff=split&name=2015_2mb_blocksize
BIP102 is normally a hardfork. The softfork ve
On 2015-12-21 12:23, jl2012 wrote:
I proposed something very similar 2 years ago:
https://bitcointalk.org/index.php?topic=283746.0
Yes there are similarities but also some important differences. See my
response here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012085
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 not reached.
That's not true a
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":
https://lists.linuxfoundation.org/pipermail/bitcoin-de
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 conse
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
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 maj
13 matches
Mail list logo
