Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> If you assume the client has all previous transactions, then you could
> get the transaction input's prevout (from the memory pool or disk) and
> then ExtractAddress() from it.
I now created a patch based on this idea. To avoid slowing down
listt
Am Mo, 24.10.2011, 13:09, schrieb Pieter Wuille:
> As far as your green transactions idea is concerned, maybe we could
> provide an interface
> to mark certain addresses as 'trusted', and have an RPC call to request
> all incoming
> transaction that originate from trusted sources?
That would be fi
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
> Green addresses could be implemented as a second signature in the
> scriptSig. You'd have to hack your bitcoin client, but you could
> generate a transaction that had ... as the
> input instead of .
>
> The will be ignored by old clients.
> Interesting suggestion! So if I understand correctly, would be
> the signature generated from signing the transaction with the key of a
> green address?
Sure. Or just "a key". It wouldn't have to be an actual key used in
the block chain.
> Sounds good - I guess I never thought in this directio
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote:
> 1) Get something working reasonable fast to detect current green address
> style transactions. It's fine if it is a little bit of a hack, as long as
> it's safe, since I don't expect it to be merged with mainline anyway at
> this point.
>
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen:
>> So my first shot at this is to go through the inputs of a transaction and
>> see if the scriptSig field has only two opcodes. If that is the case, I
assume that it is of the structure and calculate the
Bitcoin address from .
>> But then I start
PKI would avoid the need for the trust aggregator to be consulted for
each transaction. Obviously checking for revocation would be essential.
The CA cert can state what kind of guarantee is available.
Simon
On 10/24/2011 09:25 AM, Mike Hearn wrote:
> You know, just thinking out loud...
>
>
On Mon, Oct 24, 2011 at 8:55 AM, Gavin Andresen wrote:
> If you assume the client has all previous transactions, then you could
> get the transaction input's prevout (from the memory pool or disk) and
> then ExtractAddress() from it. That is probably a bad idea for
> listtransactions, since fetchi
>
> You know, just thinking out loud...
>
> Green addresses could be implemented as a second signature in the
> scriptSig.
I think this would solve one of the other issues I raised about the green
address idea you can have some kind of trust aggregator sign the
transactions. Merchants like M
> So my first shot at this is to go through the inputs of a transaction and
> see if the scriptSig field has only two opcodes. If that is the case, I
> assume that it is of the structure and calculate the
> Bitcoin address from .
> But then I started to wonder if this is safe. Can this be tricked
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote:
> Hi there!
>
> As part of my green address endeavor, I'm currently trying to extend the
> 'gettransaction' call to include an extra field "inputaddresses" which
> should return a list of the Bitcoin addresses associated with the inpu
Hi there!
As part of my green address endeavor, I'm currently trying to extend the
'gettransaction' call to include an extra field "inputaddresses" which
should return a list of the Bitcoin addresses associated with the inputs
of the transaction.
I understand that this is not generally possible,
12 matches
Mail list logo
