|
hopefully, this lull will kill off several (a few dozen) altcoins.
|
|
|
|
|
Hey look!
Dow goes up, Dow goes down, gold goes up, gold goes down. Meanwhile;
Bitcoin goes UP!
|
|
|
|
iirc, the utxo set takes up about 75% of RAM required to run a node. as i run 4 nodes myself, it takes a minimum of 1GB RAM to run smoothly meaning 750MB could be estimated for the utxo set itself. that's pretty big to be including in a block... Not in the block, alongside the block. Just like when people merge mine Namecoin the nmc blocks aren't included in the btc blocks. The merged-mine implementations that don't include the memory fix: (mutable vs imutable storage) and no auxpow data in cblockindex (blocks stored in memory) will eat up alot of RAM... so far only Devcoin and I0coin are the ones that have this fix and only Devcoin is running on 0.9.2 (currently in testing) with all the other fixes that bitcoin rolled up along the way included. So for most of these incompatible alt-coins who now wish to merge-mine (because I called that they would, and the ones that dont will die) are now suffering from either memory bloat issues or incorrect implementions/bugs and its next to impossible for a general programmer to port it over because its increasingly convoluted code to keep track of. which is exactly why i've been warning everyone about these leech coins or sidechains that wish to piggyback themselves onto the Bitcoin mining network to secure themselves. |
|
|
|
iirc, the utxo set takes up about 75% of RAM required to run a node. as i run 4 nodes myself, it takes a minimum of 1GB RAM to run smoothly meaning 750MB could be estimated for the utxo set itself. that's pretty big to be including in a block... Not in the block, alongside the block. Just like when people merge mine Namecoin the nmc blocks aren't included in the btc blocks. why would you do that? |
|
|
|
nah, miners who aren't paying attention, maybe. but not the protocol itself. |
|
|
|
i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time. then, the successful miner can publish the header hash along with some signal as to how far down in that list he went before he stopped adding tx's. then, all other miners will know how to verify the published header hash and remove those tx's from the utxo set before moving on to the next block.
Yes, as I understand it, the trick is the deterministic order. The "signal as to how far down in that list" is the thing gavin tweeted about. how reliable is a synced utxo set across all miners? |
|
|
|
i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time. What if the UTXO set itself is a structure that gets merge-mined with the blocks themselves? iirc, the utxo set takes up about 75% of RAM required to run a node. as i run 4 nodes myself, it takes a minimum of 1GB RAM to run smoothly meaning 750MB could be estimated for the utxo set itself. that's pretty big to be including in a block... |
|
|
|
the question is, where is that point? This is not a question we can answer. The right approach is to build a machine for constantly discovering the answer to that question in real time a.k.a a market. the other thing i don't understand is doesn't the miner who has received a valid header from another miner still have to wait for the tx's themselves to show up so he can remove them from the UTXO set before constructing the next block? Presumably you assume the miners have already seen the transactions before they see the Merkle tree, and they've seen the Merkle tree before they see the header. People who want their transactions processed, and miners who want their headers to propagate, have an incentive to make sure it is so. i think the UTXO set will have to have a pre-agreed order that will need to be synced amongst all miners in real-time. then, the successful miner can publish the header hash along with some signal as to how far down in that list he went before he stopped adding tx's. then, all other miners will know how to verify the published header hash and remove those tx's from the utxo set before moving on to the next block. |
|
|
|
It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency. No matter how much they optimize block creation, somebody (not necessarily the same entity that does the hashing) has to build the Merkle tree, and whoever they are they can't process an infinite number of transactions per second. yes, i've been asking about this on Reddit w/o an answer yet. there must be some finite time required to construct a Merkle Tree where it becomes cumbersome timewise. the question is, where is that point? As long as the ability of the network to process transactions isn't infinite, there will be some equilibrium price where the supply curve for transaction processing intersects with the demand curve.
It may just be that the price of transaction processing dropped a few orders of magnitude, which is a good thing.
The ability to provide the same service at a lower price makes the network more useful.
the other thing i don't understand is doesn't the miner who has received a valid header from another miner still have to wait for the tx's themselves to show up so he can remove them from the UTXO set before constructing the next block? |
|
|
|
What's he talking about exactly from a technical standpoint? We will need to wait for him to write up a blog summary, but my interpretation is that it is a method of propagating through the network "abbreviated" blocks which will always be the same size no matter how much Bitcoin tx volume occurs (within reason!). The full blocks would follow separately to those nodes which want them, perhaps to be known as "archive" nodes. It means that mining can happen fast on the next block without waiting for the slow propagation and verification of larger and larger blocks. It is a more sophisticated extension of the headers-first proposals. Fantastic if it can be done. To the moon and all that... It would also mean that the current incentive to keep block sizes small due to increased orphaning probability would be removed ... and the block size limit debate is back on the table with more urgency. Good point. But doesn't constructing a huge Merkle Root take longer than a small one? |
|
|
|
What's he talking about exactly from a technical standpoint? |
|
|
|
movin up faster. flight to safety:  |
|
|
|
oops. the Dow after hours:  |
|
|
|
movin on up:  |
|
|
|
much more favorable outlook towards Bitcoin abroad than here in the US:
A recent survey by mobile payment company Jana found that over half of respondents from Asia and Africa expressed confidence in investing in bitcoin. Consumer confidence is especially high in Kenya, home of M-Pesa, and 74 percent of Kenyan respondents said they would feel comfortable investing in digital currency.http://www.forbes.com/sites/techonomy/2014/08/07/bitcoin-momentum-grows-in-emerging-markets/ |
|
|
|
|
Show Posts
