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<pair<opcodetype, vector<unsigned char> > > vSolution;
if (!Solver(scriptPubKey, vSolution))
return 0;
BOOST_FOREACH(PAIRTYPE(opcodetype, vector<unsigned char>)& item, vSolution)
{
vector<unsigned char> vchPubKey;
if (item.first == OP_PUBKEY)
// encode the pubkey into a hash160
return Hash160(item.second);
else if (item.first == OP_PUBKEYHASH)
return uint160(item.second);
}
This possibility is used today in:
* blockexplorer
* bitcoin-js
* my own tiered implementation for thin clients
I agree that you can of course always construct payment schemes to hide
payments (hashes from classic novels, sending the private key off line etc),
but I consider those either exotic or on purpose hidden, and hence they are not
really a problem, nor an argument that this feature does not really exist today.
So, if we introduce a standard (multikey) payment that hides the address (or
makes it overly complicated to extract it) it will be a major problem for the
projects that I listed above.
I will post a more detailed technical comment reflecting directly on the BIPs,
but the wiki is currently down and I need to re-read the BIPs first.
Cheers,
Michael
On 25/10/2011, at 18:47, Alan Reiner wrote:
> On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <[email protected]> wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <[email protected]>
> 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 that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
> (1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
> multi-signature transactions. It sounds like to me, that you can still use
> the regular OP_CHECKMULTISIG if you are concerned about these things. If
> you're dealing with too many parties with questionable reliability that they
> will notify you of transacitons that include you, I don't see anything wrong
> with declaring that you'd only prefer dealing with OP_CMS transactions and
> not OP_EVAL (besides some grumbling from them that their way is "better").
> Either way, they're screwing themselves, too, if they want to include you on
> transactions and don't notify you as such (kind of defeats the purpose of
> multi-sig txs).
>
> (2) I think it's unnecessary to discuss cases where you somehow lose your
> mappings but not your private keys. In order for OP_EVAL scripts to work,
> the subscripts/mappings are *just as important* as your regular private keys.
> They should be kept in your wallet forever just like your private keys--and
> thus you lose none of them or all of them. The only real difference is that
> they aren't sensitive like your private keys, so they don't have to be
> encrypted.
>
> (3) There should most definitely be a button on the main client that allows
> you to "Add OP_EVAL script" or something along those lines (maybe something
> with a less obscure name). We need to make it as easy as possible for
> someone to add such a script/mapping to their wallet. Although, this invites
> a breach of one of my core rules of user interfaces: if the functionality is
> dependent on the user performing some regular maintenance task, you better be
> prepared for all users to fail at doing it. Even diligent users are going to
> forget/mess-up sometimes. If failure at performing this task results in
> breaking the client or losing money, we should avoid promoting that usage
> paradigm.
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev_______________________________________________
> Bitcoin-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Bitcoin-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
