Below an excerpt from the API offered by the bitsofproof supernode. The database it maintains is also queryable if you use the SQL option. Both LevelDB and relational storage options are optimized to answer below APIs that are RMI calls to the server. /**
* get transaction outputs that could be spent by the adresses
*
* @param address
* @return list of outputs, eventually empty
*/
public List<TransactionOutput> getBalance (List<String> address);
/**
* get account statement
*
* @param addresses
* @param from
* - unix time point the account statement should start from
* @return
*/
public AccountStatement getAccountStatement (List<String> addresses, long from);
|
|
|
|
It sounds like SIGHASH_ALL is the hidden magic solution, that prevents parties from reordering or tampering.
Edited example accordingly.
Documentation on SIGHASH_*, particularly on the wiki, is severely lacking.
Unfortunately all values not SIGHASH_NONE, SIGHASH_SINGLE are interpreted as SIGHAS_ALL and that even enters into the digest of the transactions. Therefore defining and using a new SIGHASH_* is only possible if that was not yet used in the chain otherwise we fork. I already saw transactions using some random value in that byte. |
|
|
|
* I suspect that we long ago passed the point where the majority of blocks are generated by software other than the reference client. I could very easily be wrong about that, but I think that most pools are running custom software to generate blocks according to their own local rules.
I'm certain that you're wrong there. The attempts that I'm aware of that have gone even somewhat close to this have resulted in invalid blocks, so if it was widely being done the invalid blocks would probably be noticeable. Really? Assuming that you have the transactions already, assembling them into valid blocks is incredibly easy. Wasn't that the whole point of getblocktemplate? It is not as easy as it sounds since you have to be carefully choosing those not only unconfirmed and valid, but those that have inputs confirmed in previous blocks and you have to order the rest such that they can be processed in that order (since outputs might be reused in the same block). You also have take into account various limits for the block in size and in number of signatures... to mention a few. In addition you might have further preferences on transaction selection as miner. Even on the question on which block to build if two are competing. There is a whole lot a server that prepares block templates can do for you. |
|
|
|
the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250). Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)
I think this applies to inclusion into blocks not relaying. There are no "requirements" for getting into a block, beyond having valid signatures and not-yet-spent inputs.* The rules gmaxwell cited are in the Satoshi code where compiling new blocks. I do not know if miner use this. They are not used for relaying, and that was my point. |
|
|
|
|
You only need one computer to create any number of payments.
In case you pay fees they will be guaranteed relayed. The fees you pay go to the miner not your other computer.
You might get tired of subsidizing them.
|
|
|
|
the transaction will not be relayed if it doesn't pass all the free criteria: no dust outputs, small size, and priority greater than 57600000 (COIN * 144 / 250). Priority is the sum(value*confirms)/data_size. (Otherwise someone could flood out the whole network easily)
I think this applies to inclusion into blocks not relaying. |
|
|
|
|
I wonder if zero fee transactions should be relayed at all, since the minimum fee is so low (0.0001 BTC) it should not prohibit any legit use.
|
|
|
|
I have following questions:
a) What happens to all the transactions from the original chain that happened after the 1.000.000 BTC transaction ? Are they all erased from existence ?
Your question (all other follow from this) is not special to an attack. The block chain is actually a tree. It is quite frequent (nearly every day in my experience) that alternate blocks compete to succeed the latest. It is less frequent but still a regular event that more than one blocks are orphaned (superseded) by an alternate branch. Transactions that are in the orphaned blocks become invalid only if their input was also used in the now longest chain (say the trunk of the tree). Quite a few transactions will actually already be in the trunk (if it is not a real and nasty attack). Those transactions that remain valid but are not already in the trunk should enter the unconfirmed pool of the node. I have not checked the Satoshi code if and how far it scans the orphaned branch to recollect unconfirmed transactions, but I assume it does reasonable effort to do so. The bitsofproof supernode does this consequently entering every otherwise missed transaction in the orphaned branch into its unconfirmed pool that is used to build block templates for mining. It also re-broadcasts transactions that became unconfirmed in a freshly orphaned block. The unconfirmed pool is most likely in memory for all node implementations therefore there remains the chance that valid but unconfirmed transactions will cease at some (long) delay from the memory of the network. It is the interest of the economy to minimize transaction drop through block orphaning, that is just a technical event and has no meaning to end user, and it is also the interest of miner to re-collect fees offered in unconfirmed transactions. |
|
|
|
The bitsofproof supernode now features an asynchronous communication bus with corresponding API to subscribe to validated transactions, block chain events (extension, reorg) and block templates. The bus allows submission of mined blocks and new transactions and is supported by a generic purpose JMS message broker, in my case Apollo MQ. The use of such message broker allows efficient message distribution to a large number of known counterparts, while taking care of authentication and authorization to publish or subscribe to different topics the messages are queued on. Both server and evtl. clients connect to the bus using SSL sockets over the internet. Also added documentation on configuration and database schema overview in: https://github.com/bitsofproof/supernode/wiki |
|
|
|
It is how the world outside Bitcoin works. Companies use a limited number of accounts to reduce audit effort. What is an "account", if not an arbitrary grouping of transactions? What happens if you call an extended public key (defined in BIP32) as an "account"? The extended public key is a single unique identifier so there's no reason not to consider the root address and all its children to be a single "account". That it can be subdivided into a hierarchy is just an implementation detail. Yes, an account is just a grouping of transactions. The only grouping currently commonly implemented is by address. Assuming BIP32 is implemented, then the audit would have to include every address for which public key derivable from the extended public key. But, how would an auditor tell if he/she has to check transactions only for the n-th key but not check if there are any key n+1 or even key n + m? |
|
|
|
Merchants may actually opt for re-using the same account frequently to have simpler audit.
Is this hypothetical merchant who is reusing a single receiving address doing all his accounting on an abacus? It is how the world outside Bitcoin works. Companies use a limited number of accounts to reduce audit effort. This is an other use case, probably not yours, but that does not mean it is wrong. |
|
|
|
My poorly formulated point was that for deterministic wallet you start with a key pair including the private one. Derivation of further keys both public and private is possible, but not just public without having at least one private in the first place.
Not sure I understand you correctly, but type-2 deterministic key derivation (like BIP32, Electrum and Armory do) allows derivation of just the public key when you only have a root public key (without any private key at all). Yes, you can come up with further public keys and you need to have only one private key and that does not need to be on the server. I learned several ways to do so in this thread. |
|
|
|
|
While I understand your concern for privacy, this should be an option and not default, since a cost to the system.
Merchants may actually opt for re-using the same account frequently to have simpler audit.
|
|
|
|
Anonymity: To the extent possible I don't want to use outputs from different addresses as inputs in a single transaction. If I need to pay Bitmit 10 BTC but all I have are two 6 BTC outputs on different addresses I can use two transactions to complete the sale by sending 6 BTC to address k and 4 BTC to address k+1. Now it will be more difficult for a third party to examine the blockchain and determine that the same individual controls both addresses.
This is a use-case that isn't captured in BIP 0032 and I think should be. The "main" way we associate addresses with a single identity is when those addresses are used as multiple inputs in a transaction. We certainly could form separate transactions while using a single input for each but if all those transactions are being sent to the same address at roughly the same time, the assumption could still be made that those addresses were all associated with a single identity. With BIP 0032, the client could instead generate multiple transactions to unique derived public addresses. This would go a significant way towards removing this particular information leak. I understand that anonymity is a concern for quite a few users or transaction types, but that comes at a cost to the system since all solutions that try to avoid recombining inputs imply that coins will be fragmented to exponentially growing key set. That might not be a problem for the individual but is already a significant and growing issue for miner (and transaction validating clients) since lookups for unspent output have to work on an ever (and exponentially) increasing set. What about bargaining the interest for anonymity of the individual with that of the system by requiring that minimal transaction fee increases with growing imbalance of number of inputs and outputs ? That is: miner would accept transactions that aggregate inputs at lower fee and ask for proportionally higher fee if number of outputs exceeds that of the inputs? |
|
|
|
|
What about balancing privacy concerns with economic interest of the economy (that is to contain dust) by requiring higher minimum transaction fee if number of inputs less than number of outputs ?
|
|
|
|
|
Would it not solve the problem to change default client behavior to prefer aggregation while choosing input for the transactions?
It does not have to be radical collecting all dust in a single transaction but have a tendency to use at least as many inputs as outputs.
|
|
|
|
If you'd find an algorithm creating a chain of public keys without first creating the private keys, that would mean you broke the EC algorithm and Bitcoin with it.
False. There are multiple deterministic wallet implementations and they do not break the EC algorithm, they use it. Armory and electrum both have deterministic wallets and the Satoshi client is working on one, too. https://en.bitcoin.it/wiki/BIP_0032They set the rules for the private keys. Not the public. I'm not really sure what you are trying to say. With Armory it works like this: Wallet on an offline computer and a master private key, master public key and a chain code. Wallet on an online computer with the master public key and the chain code. This computer can generate an essentially infinite chain of public keys that correspond to the chain of private keys on the offline computer. The chained private key need not be created before the chained public key. This does depend on the master private key being generated first. Is that what you are referring to? The OP didn't say anything about wanting an algorithm for that. My poorly formulated point was that for deterministic wallet you start with a key pair including the private one. Derivation of further keys both public and private is possible, but not just public without having at least one private in the first place. |
|
|
|
|
It is not the number of 0 that is set as target but a number that the result must be less than. This allows lower granularity of adjustment.
The merkle root is simplified a checksum of the block content that is included into the data the hash has to be found upon, therefore it serves as a proxy for the block content. it has other neat properties too, but this should answer your question.
|
|
|
|
|
The link with some order id is really elegant mskwik!
|
|
|
|
|
Show Posts
