|
This has been extensively discussed on the forum and elsewhere. Use the search box.
|
|
|
|
I don't think they will. Personally I don't think inputs/outputs are inferior enough to change it at this point.
As said, the refactor would be big, and you would need a hard fork. But I'm still missing why Satoshi didn't make it a balances ledger from the beginning.
It protects against reorganization attacks. I don't see why reorgs are a problem using sequence numbers to serialize the transactions from an address. But that makes you remember empty addresses and their sequence numbers forever to avoid replays. If they used the hash of the last transaction from each address, you could forget about empty addresses or "destroy accounts". If you add a hash of the previous transaction, and if you extend your proposal to allow transactions to include more than one parent input, then guess what? That exactly describe the transaction output system bitcoin actually uses. I don't think they are as different as you or LvM think they are. |
|
|
|
The downside to only having the (txid:n, script) one's digest committed in the block header is that you can't concisely prove a utxo with a given script doesn't exist. But you can still concisely prove when one does, and that seems to be what's really important. No, you need to be able to prove both, otherwise we're right back where we started from in terms of scalability and lightweight clients. One data structure is needed for creating transactions, the other is required for validating transactions. It's rather silly and myopic to optimize one without the other, and I will accept no compromise - both will be authenticated and committed so long as I have any say in it. Transactions within blocks are processed in-order, and so cannot depend on later transactions.
Okay, but I don't think an individual block really needs to encode an explicit ordering of transactions, as the tx DAG is the same for any valid ordering. As long as a node can find some ordering that's consistent, then that's good enough. I'm simply reporting how bitcoin works: if you include transactions out of order, your block will not validate. |
|
|
|
|
An index keyed by (txid:n) will have to be maintained for block validation anyway. My current plan is to have one index (hash(script), txid:n) -> balance for wallet operations, and another (txid:n) -> CCoins for validation.
Transactions within blocks are processed in-order, and so cannot depend on later transactions.
|
|
|
|
I've pushed an in-memory hybrid PATRICIA-Braindais tree implementation to github: https://github.com/maaku/utxo-indexI may experiment with the internal structure of this tree (for example: different radix sizes, script vs hash(script) as key, storing extra information per node). 2-way tries probably involve way too much overhead, but I think a convincing argument could be made for 16-way tries (two levels per byte). Once I get a benchmark runner written we can get some empirical evidence on this. Having sub-trees isn't so much about address reuse as it is that two different keys are needed: the key is properly (script, txid:n). In terms of implementation difficulty I don't think it's actually that much more complicated. But again, we can empirically determine this. |
|
|
|
If you are talking about pairs of adjacent blocks all you've achieved is making validating the chain possibly a bit cheaper, *A lot* cheaper. But anyway: those creating the blocks still need to have the full UTXO set. To create a transaction you only need access to your own inputs. Why would you need the full UTXO set? Going back to the merkle tree thing it occurs to me that achieving synchronization is really difficult. For instance if the lowest level of the tree is indexed by tx hash, you've achieved nothing because there is no local UTXO set consensus. Can you explain this? |
|
|
|
|
Coinbase works pretty well too.
|
|
|
|
A few people have asked how much coin it would take. For the Freimarkets proposal I can give hard numbers: for me going alone, it'll take $54,000 (or equivalent in bitcoin, but expenses are in dollars & euros so I will quote fiat), and 12 months of development. This includes development of the unspent-TxOut indices that I am currently working on, which I see as a necessary technical prerequisite, but work could be done on both in parallel. For about 50% more - $84,000 - I could bring on board a second full-time developer and deliver 2-3 months earlier and with better quality code and test coverage. Beyond that coordination cost of adding new people probably outweighs any gains, unless you are interested in funding user interface development or other ancillary features. And by the way, I've already quit my day job so the clock has started. So long as we can continue to find funding, expect delivery of UTXO indices in 6mo, and Freimarkets 6mo thereafter. Assuming, of course, that the community continues to be generous with providing bitcoin to keep me/us going. dacoinminster, this is your thread, so it'll be my last post about Freimarkets. But there's your plan B  We would welcome you as an investor. |
|
|
|
dacoinminster, the project you are seeking to start is already underway. I'm not sure if you remember, but we met at the conference after your panel. As I said then, we the Freicoin developers have been working on a proposal with similar goals for some time. It now has a name: “Freimarkets: assets, credit, and exchange”. Explained in bitcoin terms, it is basically colored coins on steroids, plus decentralized, distributed p2p markets. Together with the “smart contracts” possible though the bitcoin scripting language, these provide all the primitives necessary for the issuance and management of just about any kind of financial instrument. We are currently working on a white paper describing in detail the modifications to bitcoin protocol, but here is the high-level executive summary: Therein we propose a new transaction format, nVersion=3 transactions (Freicoin's interest/demurrage modifications having defined nVersion=2), which enable one level of independently verified sub-transactions, as well as relaxation of the rules regarding coin generation via coinbase transactions for the purpose of supporting user-defined assets on the block-chain. Combined with suitable extensions to the peer-to-peer, JSON-RPC, and user interfaces, these two protocol changes complete bitcoin’s repertoire of low-level constructs, allowing the emulation of a wide variety of financial instruments. Together this enables the following sorts of applications: * Issuing new assets by means of asset definition transactions (coinbase transactions other than the usual first transaction of a block), then transferring ownership of these “colored coins” through normal Freicoin transactions. Such assets are allowed to specify their own interest/demurrage rate, reference an external legal contract (typically governing their redemption) and may be destroyed when no longer needed by a special class of non-spendable, prunable output script. * Atomic exchange of assets of differing types through inclusion of inputs and outputs for both in a single transaction. * Signing orders (partial-transactions) that are binding but not completed until they get into the chain as part of a balanced transaction, and have attached expiration dates or can be explicitly cancelled by double-spending the signed inputs. * Executing an arbitrary number of these orders atomically by creating a complete valid transaction where the orders are included as sub-transactions, thereby executing an atomic trade/exchange without requiring both parties to be online or in direct contact with each other. * Composing orders from separate markets into an atomic trade with intermediate assets, enabling payment based on transitive trust relationships In other words, any of the multitude of things Open-Transactions or Ripplepay were designed to do, could now be done on the block chain. Further, there is no reason why this could not be implemented on Bitcoin itself. However, it is such a drastic change in scope from what bitcoin has traditionally been that getting the required consensus may not be worthwhile or even doable. The smaller, more focused Freicoin community has already rallied behind this as the next major technical development, and it will be deployed to that network within as soon as development and testing is finished. As you may know, I'm currently working on UTXO indices for bitcoin, and you would be excused for wondering how these two proposals could be related. The thing is, we anticipate user-issued assets and distributed exchange to grow demand for blockchain transactions considerably. Actually considerably is an understatement: I would not be surprised if it exceeds regular bitcoin traffic by a factor of 100x or more. Therefore we are working to get UTXO indices implemented first so that the core bitcoin layer can scale, then implement “Freimarkets” on top of Freicoin. Using existing scripts, users would be able to make atomic trades across chains (bitcoins <--> freicoins), and then use Freimarkets to issue their own transactions or participate in the p2p exchange. I obviously feel Freicoin will succeed as a currency, on its own merits. However playing devil's advocate, even if you are not bullish on FRC it's still true that it's unique system of demurrage makes it an ideal fee currency that doesn't threaten bitcoin's utility as store-of-value. And the scale of hard-fork changes required for Freimarkets makes it a non-starter on bitcoin itself for pragmatic reasons. Your idea about exchanging NewCoins for the bitcoin crowdfund investment is interesting, but unfortunately mismatched to the current situation on the ground. If you want to invest in this new idea, invest in freicoins - they will soon be the fee currency for the proposal. If you have bitcoins to contribute to the effort then contact me offline. My time is only paid for for the first couple of months, but this is expected to be a year-long endeveour. If additional funds were available, I'd be able to bring on extra programmers to make it happen sooner. (I already have one in mind, but if anyone technical is reading this and interested, contact me offline.) |
|
|
|
|
I thought Gavin said ordinary people don't care much about anonymity. I'm not sure I concur, but it is a valid and important distinction between privacy and anonymity. With the right tools bitcoin does well with the former. Zerocoin addresses the latter.
|
|
|
|
What can your coin do that LTC/BTC can't? Lose value! |
|
|
|
|
Adam very well was in a position to be Satoshi - bitcoin is just a different application of the same technical ideas. I will take his word that he is not. If you want to debate it, you should probably do it somewhere else.
|
|
|
|
|
My point is that the same argument applies to Open-Transactions, or any other known distributed money system, except perhaps zero-knowledge proof systems which are still theoretical. In Open-Transactions you are given the information necessary to audit the server's actions. If you want to make an apples-to-apples comparison, you should be accounting for this computational cost incurred by users who do such validations.
|
|
|
|
It comes down to maths.
No, it's a little disingenuous to make such an argument: The cost to check the inputs of a transaction is:
O log(total number of unspent outputs).
It could very well be constant, if a hash table were used. The cost of checking any one transaction is:
O (number of full nodes) * (cost of checking a transaction).
There is no protocol reason why more than 1 full node needs to be running. If there are N full nodes, it is because N-1 people decided it was a worthwhile investment of their time and resources to do so. Open-Transactions runs with a single validating node, the server. But audit information is (in theory) available so anyone can check that the server isn't lying. And if they were to do so for all transactions processed by the server, then it would incur the same overhead. Now typically in Open-Transactions one only verifies their own receipts, but the same could be said for SPV/SPV+ clients. The cost of growing the network with a constant number of transactions per user is:
O (number of users) * (cost of the network checking the transaction)
Which with your qualifications is essentially saying that the cost of full validation scales linearly with the number of transactions. No surprise there. |
|
|
|
 "In 2012, under threat from fundamentalist rebels, a team of archivists, librarians, and couriers evacuated an irreplaceable trove of manuscripts from Timbuktu at great personal risk. The manuscripts have been saved from immediate destruction, but the danger is not over. A massive archival effort is needed to protect this immense global heritage from loss. "Though removed from immediate threat, the manuscripts are still jam packed in footlockers used for their evacuation and the current environment of this precious world heritage is significantly more humid than Timbuktu. There are already signs of damage and exposure to moisture. "The purpose of this campaign is to fund the preservation effort required to store the manuscripts in an archival, moisture-resistant manner during their exile from Timbuktu. If physical harm from the current packing situation continues and if mold and mildew spread in the corpus due to increased humidity, the damage will be devastating." You can read more about the project on their Indiegogo campaign: http://www.indiegogo.com/projects/timbuktu-libraries-in-exile/x/761158?c=home...and after prodding they are accepting bitcoin for donations: 1KFNd93GHyNWy36UfqGtTriv733Xs7eXMVPlease look at their funding campaign, their video, and consider sending some bitcoin. This is a written literary tradition that is in danger of being destroyed by short-sighted fundamentalists. It's not every day that a few bit-cents can make a difference to the repertoire of human traditions. |
|
|
|
|
Am I reading the source code correctly that you are doing a standard Merkle-list for the UTXO tree? I couldn't find anything that looked like balanced tree updates. I'd think that's the root of your inefficiency right there - PATRICIA trees are a big part of this proposal.
You are right that this impacts Electrum significantly. We should coordinate our efforts.
|
|
|
|
All of these off blockchain ideas are all trying to solve the problem that Bitcoin solves, without using the amount of resources that a solution requires. It's never going to work out that way. If somebody does find a way to solve the decentralized transaction ordering problem in a way that's better than Bitcoin that technology isn't going to be an add-on to Bitcoin - it's going to be a new currency that replaces Bitcoin.
All of this effort around designing alternatives to the blockchain would be more effectively employed making the blockchain work. It's not going to be any easier to scale an off chain transaction processing system to huge rates and keep the same level of security and censorship resistance than it would be to scale the blockchain to the same level.
Quoted... because it deserves to be said again. Thank you, justusranvier. |
|
|
|
|
Oh, my conservative position is still that prefixing the index key is the wrong way to solve this problem, but I'm willing to explore the idea.
|
|
|
|
|
Show Posts
