Peter, I like the idea of being able to know what fees to expect from different
miners (it is like a service description / SLA for their service), but I would
prefer a more distributed discovery mechanism for the information on the fees
(Spent 10 years on Grid Computing...).
Miners could e.g.
On Tuesday, May 29, 2012 3:05:18 PM Peter Vessenes wrote:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
Without my got-tired-of-waiting-for-someone-to-merge-it coinbaser branch,
anything modifying the coinbase is hard to implement.
2)
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
I don't understand what the 20 byte keyhash is. Can you elucidate?
20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
ripemd160(sha256(ecdsaPubKey))
OK, I have a few thoughts on this:
1) Germane to the original conversation, anything hard to implement will
not get implemented by miners.
2) Coinbase is hard-limited to 100 bytes; this has to include space for
voting as well as extra nonce, etc. So, I'm not sure that a full URL is a
good plan.
I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
Best,
Peter
On Tue, May 29, 2012 at 11:34 AM, Luke-Jr l...@dashjr.org wrote:
On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
I
On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
I suppose I mean that I don't understand how to reverse that into a URL
when one is presented only with a block, or perhaps a coinbase in a
transaction.
A new message can be added to the p2p relay network, similar to tx and alert
I see. That is undeniably more secure and bitcoin-y than my suggestion.
It's also really a lot more work, especially in that it requires extra
linkages between codebases that in my mind are largely separate.
I'm just one voice, but I persist in believing that the 'lighter' solution,
especially
I disagree with a bunch of your points, but I'll wait on others to comment,
except I will say that I don't understand what the 20 byte keyhash is. Can
you elucidate?
I am assuming major mining folks have written their own coinbasing
facilities, but perhaps this is not the case -- if so, I agree
I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed,
We just implemented our own mining tool, soup-to-nuts, and I would say that
the likely motivation for what I presume are botnet owners is just economic.
It's a lot more work to make sure your merkleing and keeping up-to-date are
happening than it is to just get an 80 byte header from a central
For what it is worth, I question whether this is a problem. Or, I
guess I question whether the best solution to it isn't for people to
start including more transaction fees. In fact, I'm not entirely sure
that this problem doesn't actually *encourage* people to that
solution, which would be very
There appears to be some non-trivial mining power devoted to mining
empty blocks. Even with satoshi's key observation -- hash a fixed
80-byte header, not the entire block -- some miners still find it
easier to mine empty blocks, rather than watch the network for new
transactions.
Therefore I was
I think you need the stronger change. Otherwise, the mystery miner could
just put in a few transactions to himself to mask his block. His block
would appear to be of some use while not being helpful.
-Arthur
On Thu, May 24, 2012 at 9:33 AM, Jeff Garzik jgar...@exmulti.com wrote:
There
I think the strong verification would go well if you add it along with an
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
On Thu, May 24, 2012 at 7:33 PM, Jeff Garzik
On Thu, May 24, 2012 at 1:13 PM, Joel Joonatan Kaartinen
joel.kaarti...@gmail.com wrote:
optimization that avoids rechecking transactions that have already been
verified as valid. Any transactions it doesn't have to verify are from the
pool, of course :)
Work in this area is already
On Thu, May 24, 2012 at 1:27 PM, Robert McKay rob...@mckay.com wrote:
If miners wanted to continue mining empty blocks without bothering to
monitor the Tx pool they would just switch to stuffing the empty blocks
with a dummy transaction of their own to get round your new rules.
Yes. This was
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
There appears to be some non-trivial mining power devoted to mining
empty blocks. Even with satoshi's key observation -- hash a fixed
80-byte header, not the entire block -- some miners still find it
easier to mine empty blocks, rather
On Thu, May 24, 2012 at 4:31 PM, Luke-Jr l...@dashjr.org wrote:
These are problematic for legitimate miners:
1) The freedom to reject transactions based on fees or spam filters, is
severely restricted. As mentioned in other replies, this is an important point
of Bitcoin's design.
1b) This
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
10) of 1-txn blocks is not actually unreasonable. This also
On Thu, May 24, 2012 at 8:45 PM, Luke-Jr l...@dashjr.org wrote:
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10%
On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote:
On Thu, May 24, 2012 at 8:45 PM, Luke-Jr l...@dashjr.org wrote:
On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
Comments? It wouldn't be a problem if these no-TX blocks were not
already getting frequent (1 in 20).
FWIW,
21 matches
Mail list logo
