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,
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
Actually no, the same string may have to be translated in different ways
depending on the context they appear in. That sometimes happens for italian,
and I'm sure it happens in other cases too. Not sure whether this is the
cause for duplicate strings for now, but it might.
Regards,
Chris
On Sat,
Hahaha you mean like unitialised variables, inheriting from containers with
non-virtual dtors (CScript) and delicious copy pasta coding (PushMessage,
bignum and serialize stuff).
No need to worry about that :)
From: John Smith
To: theymos
Cc: bitcoin-develo
> 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
>
> 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
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
Indeed. It could make sense. That's the reason why Qt distinguishes strings
based on context as well as content.
But it could also be nonsense. Can you be more specific as to which strings?
JS
On Mon, Oct 24, 2011 at 1:24 PM, Christian Decker <
decker.christ...@gmail.com> wrote:
> Actually no,
Yes, you're right, there is a lot of code is in the "fun with knives"
category.
JS
On Mon, Oct 24, 2011 at 4:31 PM, Amir Taaki wrote:
> Hahaha you mean like unitialised variables, inheriting from containers with
> non-virtual dtors (CScript) and delicious copy pasta coding (PushMessage,
> bignu
Three quick examples of duplicated strings. There are many more. Some of
the smaller ones may make sense to have duplicated several times in
english as their translated versions may differ in other languages. But
with these below I don't see the point.
Twice, with a small difference ( vs. none):
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...
>
>
Those indeed seems weird... I'll take a look at it.
JS
On Mon, Oct 24, 2011 at 8:55 PM, Geir Harald Hansen
wrote:
> Three quick examples of duplicated strings. There are many more. Some of
> the smaller ones may make sense to have duplicated several times in
> english as their translated version
12 matches
Mail list logo
