It can speed up the initial chain download. A newly created wallet will
have only new key-pairs, hence no incoming transactions (unless we have a
key collision, which is unlikely). So there is no need for a bootstrapping
node to download the chain with transactions. The chain itself can be
verified
The OP_EVAL discussion went into some private discussion for a bit, so
here is a summary of what we talked about.
Roconnor pointed out that the currently proposed OP_EVAL removes the
ability to statically reason about scripts. Justmoon pointed out that
this is evidenced by the changes to GetSi
Here are my latest thoughts on a safer OP_EVAL alternative, inspired
by all the ideas and agitated IRC and email
discussions of the last week or so:
Goal: Let users publish a short "funding address" that is the hash of
an arbitrary redemption Script revealed when they spend the funds,
implemented
This meeting is to discuss the new OP_EVAL changes coming to bitcoin.
A good summary of the past discussion so far by justmoon can be found:
http://privatepaste.com/4088b049af
Hopefully this can become a weekly thing. For now this is to discuss and inform
about the coming changes to bitcoin.
--
Seems ... acceptable from first glance.
Though I propose an ammendent to either
(1)
make the script: OP_NOP1 HASH160 EQUAL to make it
extremely easy to see from the first byte that this is verly likely to be
a special transaction (or more accurately if the first byte isn't
OP_NOP1 then you i
+1. I love this proposal.
It's two less bytes than OP_EVAL even.
It allows static analysis.
It doesn't require any change to the script interpreter. (You can do a
static replacement step between parsing and execution.)
It allows all urgent use cases.
It doesn't consume a NOP. If we ever want recu
Because many made the mistake and it isnt specified in this email, this
meeting is tomorrow (not 30 minutes ago).
On Mon, 2012-01-02 at 08:04 -0800, Amir Taaki wrote:
> This meeting is to discuss the new OP_EVAL changes coming to bitcoin.
>
> A good summary of the past discussion so far by justmo
On 2012-01-02 05:31:19 -0800, Christian Decker said:
> Later full blocks would be required to detect usable inputs for future
> outgoing transactions.
Er, yes, this is what I meant; I guess I should have been more specific.
So, a paranoid client cannot confirm reciept of coins until it has an
u
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell wrote:
> On 2012-01-02 05:31:19 -0800, Christian Decker said:
>> Later full blocks would be required to detect usable inputs for future
>> outgoing transactions.
>
> Er, yes, this is what I meant; I guess I should have been more specific.
>
> So, a para
On 2012-01-02 14:41:10 -0800, Gregory Maxwell said:
> make this possible: https://bitcointalk.org/index.php?topic=21995.0
Neat! I had a similar idea but you've clearly beat me to [a big part of] it.
> Er, no— if a node controls the private keys for a transaction, and
> that transaction makes i
10 matches
Mail list logo
