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 le
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
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 18:33, Marco Falke wrote:
This is an interesting app
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
I guess the same could be said about the softfork flavoured SW
implementation. In any case, the strategy pattern helps with code structure
in situations like this.
2015-12-30 14:29 GMT+01:00 Jonathan Toomim via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> As a first impression, I think
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
On Dec 30, 2015, at 6:19 AM, Peter Todd wrote:
> Your fear is misplaced: it's trivial to avoid recursion with a bit of
> planning...
That makes some sense. I downgrade my emotions from "a future in which we have
deployed a few generalized softforks this way sounds terrifying" to "the idea
of
On Wed, Dec 30, 2015 at 06:19:55AM -0800, Peter Todd via bitcoin-dev wrote:
> On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev
> wrote:
> > As a first impression, I think this proposal is intellectually interesting,
> > but crufty and hackish and should never actually be
On Wed, Dec 30, 2015 at 12:16:22PM +0100, Martijn Meijering via bitcoin-dev
wrote:
> That looks very interesting. But is effectively blocking old clients from
> seeing transactions really safe? After all, such transactions are still
> confirmed on the new chain. A person might try to send a simila
On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev wrote:
> As a first impression, I think this proposal is intellectually interesting,
> but crufty and hackish and should never actually be deployed. Writing code
> for Bitcoin in a future in which we have deployed a few gen
That looks very interesting. But is effectively blocking old clients from
seeing transactions really safe? After all, such transactions are still
confirmed on the new chain. A person might try to send a similar
transaction several times, perhaps with increasing fees in an attempt to
get it to confi
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 requires nodes to
upgrade. Otherwise they
As a first impression, I think this proposal is intellectually interesting, but
crufty and hackish and should never actually be deployed. Writing code for
Bitcoin in a future in which we have deployed a few generalized softforks this
way sounds terrifying.
Instead of this:
CTransaction Get
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
14 matches
Mail list logo
