Jeff, I think the message you're replying to got clipped.
Satoshi's only comment AFAIK on the topic of GPU mining was to wish for a
gentlemen's agreement to postpone it as long as possible, to help make sure
the distribution of coins was as even as possible. Indeed this predated
pooled mining.
Oops, sorry, I see the subject line changed. This is what I get for working
down the thread list top to bottom :)
I think the best path forward now is to finish off getblocktemplate support
in the various tools so it's possible to pool for payout purposes without
giving up control of block
Before they got traction, yes. But he projected a bit, as anyone
could, to see the trend.
On Thu, Jul 17, 2014 at 1:22 PM, slush sl...@centrum.cz wrote:
On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik jgar...@bitpay.com wrote:
Historical note: On one hand, Satoshi seemed to dislike the early
Yes. That, and several other things. If you can figure out how to
propagate a block without re-propagating all the transactions everyone
already has, you address the large-blocks-slower-to-relay problem, and
additionally create an incentive for miners to mine blocks consisting
of publicly
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen gavinandre...@gmail.com wrote:
I'd encourage you to code up a prototype first (or at the same time), in
whatever programming language / networking library you're most familiar
with.
+1
Maybe not even using the existing p2p protocol; there could
Two more half-baked thoughts:
We should be able to assume that the majority of transaction data (except
for coinbase) has already been propagated. As Jeff said, incentivizing
nodes to propagate transactions is a very good thing (the signature cache
already gives a small incentive to miners to
On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
gavinandre...@gmail.com wrote:
But if there was some agreed-upon canonical ordering, then it should
theoretically be possible to take shortcuts in the what order.
You'd start with setof(transactions I think everybody knows about)
Select some
Hi all,
I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
* https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result)
It makes two of the 7 new rules
The rationale doesn't seem to apply to rule #4, what's so special about
that one?
Although I agree not having to support all of DER is nice, in practice I
think all implementations do and libraries to parse DER are widespread.
Given that the last time we modified tx rules without bumping version
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net wrote:
The rationale doesn't seem to apply to rule #4, what's so special about that
one?
Nothing really. If it's controversial in any way, I'm fine with
changing that. It's just one those things that nobody needs, nobody
uses, has
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
But perhaps we should investigate how many non-DER signatures still
make it into blocks first...
In the last 11 blocks (4148 transactions), apparently none.
--
Pieter
Peers exchanging mempool priority policies is great; that accomplishes
the flexibility in what txes to remember that I was going for with the
forget-filters, but much more neatly, with less overhead and some side
benefits.
Here's what I'm picturing now:
- exchange priority policies in peer
On a flood-fill network, you don't want to create a storm of I
already have this replies.
On Fri, Jul 18, 2014 at 1:39 PM, Kaz Wesley kezi...@gmail.com wrote:
Peers exchanging mempool priority policies is great; that accomplishes
the flexibility in what txes to remember that I was going for
On Fri, Jul 18, 2014 at 5:14 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
Hi all,
I've sent a pull request to make a small change to BIP 62 (my
anti-malleability proposal) which is still a draft; see:
* https://github.com/bitcoin/bips/pull/90 (the request)
*
9. New signatures by the sender
I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.
Aaron Voisine
breadwallet.com
On Fri, Jul 18, 2014 at 1:56 PM, Wladimir
I thought I'd chime in and point out some research results that might help.
Even if they don't, there is a cool underlying technique that some of you
might find interesting.
The problem being tackled here is very similar to set reconciliation,
where
peer A thinks that the set of transactions that
My apologies for posting to the wrong thread.
On Fri, Jul 18, 2014 at 5:51 PM, Emin Gün Sirer el33th4...@gmail.com
wrote:
I thought I'd chime in and point out some research results that might help.
Even if they don't, there is a cool underlying technique that some of you
might find
I thought I'd chime in and point out some research results that might help.
Even if they don't, there is a cool underlying technique that some of you
might find interesting.
The problem being tackled here is very similar to set reconciliation,
where
peer A thinks that the set of transactions that
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer el33th4...@gmail.com wrote:
The problem being tackled here is very similar to set reconciliation,
where
peer A thinks that the set of transactions that should be in the block is
S_A,
Most things I've seen working in this space are attempting to
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine vois...@gmail.com wrote:
9. New signatures by the sender
I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.
Well, you could always create a transaction with a different signature
hash, say, by changing something trivial like nLockTime, or changing
the order of inputs or outputs. Is that what you're talking about? Or
is there some sophistry I'm ignorant of having to do with the elliptic
curve math in the
Hey all,
I'm wondering if anyone can help explain to me tx
70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
(https://blockchain.info/tx/70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d)
The input signature script is:
22 matches
Mail list logo
