I'd like to garner consensus on whether anyone else thinks it desirable to
have a flag option for bitcoin to punish blocks for not including
transactions. I notice there are already pro-miner options, such as the
restricting the relaying of free transactions, and so including an option
to restrict
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 th
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
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
bro
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 wrote:
> On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> > I don't understa
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.
3)
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))
--
On Thu, May 24, 2012 at 12:33 PM, Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks.
In the last 2016 blocks, as I write this, there are only 35 1 txn blocks.
This is about 1.73%, which wouldn't be surprising just from timing
alone. Moreover
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.
>
Testnet "Mark III" will be part of the 0.7 release, and is now in the
master github branch.
"Mark III" because this is the third genesis block for the testnet. The
main reason for the reset is to get a more 'sane' test network; with the
BIP16 and BIP30 and testnet difficulty blockchain rule change
On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> The format of the sla.php page should then be specified too - but it could
> be a json-rpc call returning a json object like (as result): {
> sla_version: "0.1",
> accept_no_fee_tx: false,
> min_fee: 5,
> big_tx_fee:
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. i
12 matches
Mail list logo
