On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
> This is a ha
On Monday, December 29, 2014 9:10:20 PM Mike Hearn wrote:
> How does adding inputs to a coinbase differ from just having pay-to-fee
> transactions in the block?
Pay-to-fee transactions can be "stolen" by another block at the same or
greater height. Additional inputs to the generation transaction
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 12/29/2014 09:10 PM, Mike Hearn wrote:
> How does adding inputs to a coinbase differ from just having
> pay-to-fee transactions in the block?
If a miner includes pay-to-fee transactions in a block, those fees
could be claimed by another miner in
On Monday, December 29, 2014 7:21:02 PM Sergio Lerner wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
This is
Could you explain a bit further Sergio? I'm not sure I fully understand the
proposal.
How does adding inputs to a coinbase differ from just having pay-to-fee
transactions in the block?
--
Dive into the World of Parallel Pr
I propose to allow miners to voluntarily lock funds by letting miners
add additional inputs to the coinbase transaction. Currently the
coinbase transaction does not allow any real input to be added (only a
pseudo-input).
This is a hard-fork, and we could include it the next time a hardfork is
made
As an outside observer, I have to say I also found Peter's sardonic message
tone inappropriate for furthering the discussion.
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and d
Mike,
In all seriousness, are you on the payroll of the NSA or similar to
repeatedly attempt to introduce privacy leaks[1] and weaknesses[2] into the
ecosystem not to mention logical fallacies like ad hominem attacks;
disruption[3] and FUD[4]?
Why do you answer objections by hand waving and misdi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29 December 2014 12:49:45 CET, Thomas Zander wrote:
>On Monday 29. December 2014 11.30.42 Mike Hearn wrote:
>> With the current DNS protocol you get an all or nothing choice
>
>Its a seed. Not the protocol itself.
>
>> Firstly, Peter, get help.
On Monday 29. December 2014 11.30.42 Mike Hearn wrote:
> With the current DNS protocol you get an all or nothing choice
Its a seed. Not the protocol itself.
> Firstly, Peter, get help. I'm serious.
I think most would agree with me that, Mike, this answer is not just a little
over the line, its u
>
> Can you explain further where limitations and problems were hit?
>
Well, look at the feature list :)
The biggest need from my POV is querying support. It's awkward to try and
retrofit flexible key=value pair queries onto DNS, it just wasn't designed
for that. With HTTP it's easy. This will be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
A big one is the privacy is way too good: every DNS request goes through
multiple levels of caching and indirection, so there's no way to figure out who
made the request to subject them additional targeting.
A connection-oriented protocol gets rid
On Sunday 28. December 2014 18.25.29 Mike Hearn wrote:
> Lately we have been bumping up against the limitations of DNS as a protocol
> for learning about the p2p network.
Can you explain further where limitations and problems were hit?
--
Thomas Zander
--
13 matches
Mail list logo
