1) I guess that this "internally", stands for services such as mtgox. How do they work?... I send money to an external wallet and then they are sent to a bigest wallet and "internally" assigned to my user? So no further transaction occurs in the blockchain until my user pretends to send them out to another address? If so, any hacking could mess transaction reccords loosing Bitcoin traceabillity...?
eWallets keep a database of how much they owe to each user. When a user wants to transfer funds to another user, they just update the balances rather than make a Bitcoin transaction. 
Topic: Doubts about Merging and PrivKeys... (Read 794 times)
1) I guess that this "internally", stands for services such as mtgox. How do they work?... I send money to an external wallet and then they are sent to a bigest wallet and "internally" assigned to my user? So no further transaction occurs in the blockchain until my user pretends to send them out to another address? If so, any hacking could mess transaction reccords loosing Bitcoin traceabillity...?
2) Multisignature might be a catch here, yes! No outgoing transactions would be generated until a our signature is sent too! Obviously no way to avoid recieving, any way!
2) Multisignature might be a catch here, yes! No outgoing transactions would be generated until a our signature is sent too! Obviously no way to avoid recieving, any way!
1. You can have a transaction with multiple inputs and outputs. I don't think you'd get much in the long term, since the load on the blockchain is proportional to the transaction data size. But if you do the transfers internally rather than with Bitcoin transactions, you can avoid them being on the blockchain at all.
2. AFAIK the scripting language allows a transaction to be valid only after block X.
3. With bitcoind they're stored in wallet.dat. If you're making a custom solution you can store them wherever you want. Ideally you'd have multisignature addresses, and put most coins in a cold wallet.
4. If a user gets the private key he can forever spend any coins in the corresponding address. Depending on what you are trying to do, multisignature transactions can help.
2. AFAIK the scripting language allows a transaction to be valid only after block X.
3. With bitcoind they're stored in wallet.dat. If you're making a custom solution you can store them wherever you want. Ideally you'd have multisignature addresses, and put most coins in a cold wallet.
4. If a user gets the private key he can forever spend any coins in the corresponding address. Depending on what you are trying to do, multisignature transactions can help.
This might be naif and or strange questions, sorry...
Let's supose I create a service were thousands of users (could be talking about xxx.xxx) make micropayments (0,00x or 0,000x) to other thousand of user daily (could become hourly, etc), each user with different adresess all orriginally generated by my company:
1) How could I merge transactions as to: a) pay lower fees (0,0005), b) be responsible with blockchain size
2) How could I delay transactions?
3) Should I be the owner of such a bunch of PrivateKeys, were or how are them stored (all inside the wallet.dat files)?
4) Is there a way to forward the privatekey to the users for acessing their addreses? So how "private" is it, meaning... he gets the PrivateKey or he would "eventually" only be able to set a password (or other method) to access it?.
Thanks...
Let's supose I create a service were thousands of users (could be talking about xxx.xxx) make micropayments (0,00x or 0,000x) to other thousand of user daily (could become hourly, etc), each user with different adresess all orriginally generated by my company:
1) How could I merge transactions as to: a) pay lower fees (0,0005), b) be responsible with blockchain size
2) How could I delay transactions?
3) Should I be the owner of such a bunch of PrivateKeys, were or how are them stored (all inside the wallet.dat files)?
4) Is there a way to forward the privatekey to the users for acessing their addreses? So how "private" is it, meaning... he gets the PrivateKey or he would "eventually" only be able to set a password (or other method) to access it?.
Thanks...
Jump to: