>
> How would I know that unless you told me?
At least you would have a hunch that something like that had happened as one of
your addresses had been part of a transaction (at least in my setup it would
pop up immediately...).
>
> I think the right long-term solution is moving away from bitco
RE: buying me and Gregory a shared beer:
> I would make a "both of two" btc-addresses script transaction using OP_EVAL.
> And post it.
> You would then not be able to know that you actually got a beer unless I told
> you so in a mail.
But that transaction won't show up in my bitcoin wallet as b
> Could you suggest how else we could gain the advantages of op_eval
> without it? How can I secure my wallet under whatever scheme I like—
> create a trust that requires multiparty signoff— and securely have
> senders pay into it without expecting them all to handle some rare and
> complicated p
(taking this a bit out of order)
On Thu, Oct 27, 2011 at 3:32 AM, Michael Grønager wrote:
> OK, let me try to explain what I see is the problem:
[snip]
> This, I find a nice and clean setup, where cryptographic keys can be mapped
> to assets.
From my perspective that clean boundary remains: Fun
OK, let me try to explain what I see is the problem:
So far we the bitcoin addresses are (for all practical purposes) a one-to-one
mapping between a pubkey and uint160. This mean that your wallet is defined
solely by your privatekeys (from which you can extract pubkeys and then uint160
btc-addr
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager wrote:
> I think it is a very important feature to be able to extract transaction
> to/from you only from your private keys.
Why? If somebody is sending me bitcoins, then they'll have to get
either an address or one or more public keys from me. O
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager wrote:
> I think it is a very important feature to be able to extract transaction
> to/from you only from your private keys. In the standard transactions this is
> easily accomplished - in the case you only want to find the addr to tx
> mapping:
I think it is a very important feature to be able to extract transaction
to/from you only from your private keys. In the standard transactions this is
easily accomplished - in the case you only want to find the addr to tx mapping:
vector > > vSolution;
if (!Solver(scriptPubKey, vSolution))
On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you pr
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen wrote:
> You give the hash to whoever is paying you, and store the hash -->
> script mapping when you do that (assuming you're not using a
> deterministic wallet; if you are, you probably just increment a
> counter in the wallet).
If anyone finds t
On Tue, Oct 25, 2011 at 6:49 AM, Mike Hearn wrote:
> scriptPubKeys that use OP_EVAL contain a hash of a script. If I
> understand correctly, that means to detect a transaction in a block
> that is relevant to your wallet, that means you need to pre-calculate
> every possible hash that might appear
scriptPubKeys that use OP_EVAL contain a hash of a script. If I
understand correctly, that means to detect a transaction in a block
that is relevant to your wallet, that means you need to pre-calculate
every possible hash that might appear.
For the case of a single payment, that's not a problem. I
12 matches
Mail list logo
