On Fri, Jul 18, 2014 at 8:06 PM, Emin Gün Sirer wrote:
>
>> Most things I've seen working in this space are attempting to minimize
>> the data transfered. At least for the miner-interested case the round
>> complexity is much more important because a single RTT is enough to
>> basically send the w
Hey all,
I'm wondering if anyone can help explain to me tx
70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d...
(https://blockchain.info/tx/70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d)
The input signature script is:
304402206b5c3b1c86748dcf328b9f3a65e10085a
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
> Most things I've seen working in this space are attempting to minimize
> the data transfered. At least for the miner-interested case the round
> complexity is much more important because a single RTT is enough to
> basically send the whole block on a lot of very relevant paths.
Agreed. Yaron's s
On Fri, Jul 18, 2014 at 3:03 PM, Aaron Voisine 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.
Nope.
Your h
On Fri, Jul 18, 2014 at 5:54 PM, Emin Gün Sirer 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 minimize
the da
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 tha
My apologies for posting to the wrong thread.
On Fri, Jul 18, 2014 at 5:51 PM, Emin Gün Sirer
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 interesting.
>
> The probl
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 tha
> 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 w
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn wrote:
> The rationale doesn't seem to apply to rule #4, what's so special about that
> one?
> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig
> invalidates it.
Having non-push operations in the scriptSig is a source of
malle
On Fri, Jul 18, 2014 at 5:14 PM, Pieter Wuille 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)
> * https://github.com/sipa/bips/blob/bip62up/bip-0
Related: We must handle some legitimate miner-privately-mined cases,
such as miner payout TXs (outside coinbase) or side chain conditional
TXs[1].
[1] https://bitcointalk.org/index.php?topic=676703.msg7682680#msg7682680
On Fri, Jul 18, 2014 at 3:51 PM, Kaz Wesley wrote:
> I've updated the gist,
I've updated the gist, and added an additional proposal that I think
meshes well:
https://gist.github.com/kazcw/43c97d3924326beca87d#ultra-fast-block-validation
sparseblocks + UFBV would tighten the new-block process to this (when
txes have been received in advance):
- receive block (~2kB for 1000
On Fri, Jul 18, 2014 at 7:25 PM, Pieter Wuille wrote:
> On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille
> 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.
Or even in the l
That's true, but I think it can be balanced with the usefulness of
knowing what messages a node has received. An invack would be sent if
N invs have been received without any resulting getdata; since we're
keeping track of peer inv order, one message can cover an arbitrarily
large series of invs.
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 wrote:
> Peers exchanging mempool priority policies is great; that accomplishes
> the flexibility in what txes to remember that I was going for with the
> forget
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 introdu
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille 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
-
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn 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 never been standar
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
n
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 mandat
On Fri, Jul 18, 2014 at 10:53 AM, Gavin Andresen
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 subset, based on mi
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 prop
On Thu, Jul 17, 2014 at 6:46 PM, Gavin Andresen 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 be a mining-only
>
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 broadca
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 wrote:
>
> On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik wrote:
>>
>> Historical note: On one hand, Satoshi seemed to dislike the early
>> emergence of GPU mining poo
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 creatio
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.
---
29 matches
Mail list logo
