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
-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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 29 December 2014 12:49:45 CET, Thomas Zander tho...@thomaszander.se 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,
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
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
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
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
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
-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 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 are
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
sergioler...@certimix.com 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
13 matches
Mail list logo
