Feature: smarter funder recognition code.

[joates]

i added this small 2nd donation as a test case..

here is the tx link

• there is no doubt that new funders will always need to paste in the tx url to become "recognized" by the system, but they should only need to do this once ( unless they send from a different --and unknown-- wallet address to deliberately become anonymous )
• as mentioned in cache properly #46 by @dominictarr improvements to the github api code will require the use of local storage for persistence.

having local storage available creates an opportunity to additionally fix this issue, by..

1. having github user identities plus the (1 or more) wallet addresses that they want to be associated with stored in the database
2. ability to traverse the blockchain tx recursively until either
   • a 'known' wallet address is located or
   • a tx without an out-going transfer address is found (see screenshot above)
     i.e. top of the stack, and therefore unclaimed if the final address does not match

does this scale ?

• 1 trip to the database (return all the github users and the wallets known about)
• we are not traversing every tx in the blockchain, the tx are all linked so it's only going to be a few hops, as the hop count grows (which it will) we can artificially inject a transaction address into the database (for that user) if we need to do more than X number of hops. (where X is just the max_hops setting)
• [edit: added ] in the worst case scenario, this can run as a background task (hourly?) that only traverses the transaction chain (on blockchain.info) and logs all the out-going transaction addresses as children to the github users initial wallet address (when a match is located), then in real-time the overhead is reduced to just a single database query ( zero XHR requests ) per funders view page load. [edit]
• so the answer is probably yes, or at least it's manageable.

and finally..

IMO this can be pushed to iteration.3 as there is already a lot in the queue for #20

[joates]

issue #5 discussions are around adding dependency on a 3rd service (1. github 2. blockchain 3. crypto client ) that seems unnecessary when all the information is contained in the public ledger.

[dominictarr]

I'm a bit confused, why do you need to traverse the blockchain?
can't you just look at the single transaction?

[joates]

all of this is new territory for me, i am also a bit confused & learning as i go.

can't you just look at the single transaction?

i guess it depends which tx you select, it's a chain, so each tx has downstream and upstream transactions (except when there is no "change" and then the chain of transactions ends), it seems that your code is currently only looking downstream, and therefore funders are required to paste in a new link to a transaction in order for them to be credited. ( because if i paste in my wallet address, which is what i actually want to be associated with the regexp will NOT locate it as it is currently implemented )

perhaps my wallet implementation is messed up?
i imported a vanitygen private key into bitcoin-qt prior to the first transaction..
i have no idea why that 2nd transaction has a different address, since i sent it from the same wallet, and afaik nothing has changed on the client end (between transactions) although i "might" have imported another private key because i'm experimenting with vanitygen ( but i don't think i did !!!) anyway thinking about that i only have btc credit in 1 of the wallet addresses so funds can only come from that address !?!!

disclaimer: i have about 2 weeks worth of "experience" with this new technology so i might be way off with my understanding of how it works, but i did read the white paper ( see section 9. Combining and Splitting Value ) which explains input and output values and why the output must spawn completely new transaction to return the "change" to the originator.

[dominictarr]

No, I mean can't I just look at the transactions that deposit into the bitcoin address that represents an iteration. We are doing that already, we just need to look for wallets we already know. we don't need to traverse any deeper than one tx though.

[joates]

look at the transactions that deposit into the bitcoin address that represents an iteration

@dominictarr yes, thats exactly correct, except in this example (see pic above) the funders wallet address is actually upstream of the tx (1 hop) and the code is only searching for a matching wallet address downstream (i.e. a child of this tx -- not a parent) and therefore it is not found and the connection to a funder cannot be made.

[dominictarr]

I don't see why you need to traverse downstream - someone who funded a iteration could have funded another project, and the maintainer of that project funds your project - but this is two different people. If someone pays directly from the same wallet, you could assume that is from the same user - but if they transfer into another wallet, then whoever controls that wallet pays you, you should assume that is a different person.

[joates]

good point, i hadn't considered that !
that scenario would certainly be undesirable, ok closing this.
( i suspect it's just my wallet that is messed up )