I want to know how many confirmations are enough to treat the blockchain immutable  On testnet? infinity? |
|
|
|
That answer is confused. Locked transactions cannot be relayed until they're about to become mineable. After they are mineable they hang around just as long as any other transaction, their persistence is not reduced. The "story" doesn't make a lot of sense, however. If someone is going to give 1000 BTC a year later with no opportunity to take it back, then that is the same as handing over the funds now. All of locktime, cltv, and CSV make sense only if there are cases where the transfer would potentially be changed but is otherwise guaranteed. Let me make it make sense: For example, your rich uncle says he will pay you 1000 BTC if you get married and stay married for a year. You don't believe him since he didn't get rich by being generous or trustworthy. So he sends 1000 BTC to a 2 of 3 multsig, with him, you, and the editor of your local paper as signers. Additionally, he writes a transaction spending that payment and paying you directly, locktimed a year from now, and he signs it and gives it to you. You sign it, so the only think keeping it from being valid is the locktime, and stick a few copies in safe places. You go and get married, confident that your uncle will not have an easy time cheating you. Now, at any point from between now and a year from now you might get divorced and then you can sign a txn giving the funds back, or-- assuming you don't co-operate he can go to the newspaper editor with evidence of your divorce, and get the funds back. Otherwise, in a year, you can take that locktimed transaction and send it to the network-- with no further cooperation from anyone else. That surprise forklift accident that got your uncle AND the newspaper editor will be no problem for you, their help is no longer required. In this case the locktime was quite useful-- and there was no reason to send it to the network until the lock was already mature... which is exactly what the network expects. If the network didn't work this way, people could make locked transactions that wouldn't be good for 100 years, use the network for free forwarding and storage.. then double spend the coins before the lock became mature to avoid paying any fees.  Fortunately, there are no interesting protocols that I've encountered where this is an issue. |
|
|
|
|
The poll text doesn't really jive with the message text.
What does Bitcoin's creator have anything to do with this? For all we know all of Satoshi's coins are happily in regular circulation.
The poll asks, "Is it morally justified to destroy Satoshi's bitcoins to prevent market crash?"
but the text of the message makes it clear the real subject is:
"If ECC is cryptographically broken, is it okay to have a finite deadline for all coins to move to non-ECC keys in order to prevent millions of coins from being stolen including long lost coins?"
These are pretty distinctive discussions... in particular, targeting a specific person is quite different from targeting vulnerable keys generally. And "to destroy" sure doesn't sound like something with ample opportunity to move them first.
|
|
|
|
looking pretty controversial in current form
You are calling a binary decomposition range proof controversial? Really? |
|
|
|
What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other. I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this. The ethereum hardfork was bilateral, probably the only thing they did right-- though it appears to have mostly been an accidental side effect due to the fact that their hardfork was rewriting their mutable state directly.. It has a benefit of being cleaner, but it is laughable to call it a "safe hardfork", because it eliminates only one fairly boring source of risk. The comparisons so soft-forks do not hold-- normally a softfork does not split the chain at all. And it is safe precisely because any fraying it causes if it causes any is not lasting, and will automatically heal without human intervention or significant disruption. all the upgraded miners will reject those small blocks produced by the minority miners, and extend the chain with small blocks mined by them, thus orphaning those small blocks
As a result, non-upgraded nodes would incur huge loss and will immediately upgrade to the new version, quickly make the hash rate on the new version almost 100% It's unfortunate to see this kind of ignorance continue. You're adopting a faulty analysis that comes from 'assuming the existence of a privileged position', why is it that you assume the non-upgraded are incurring a huge loss? By each system's own rules its own chain is valid and the others is invalid in that sense they have equal standing, but one has the moral authority of being first and consistent with the philosophy of robustness against external influence. Because of this it would be more valid to say the interlopers are incurring a huge loss if anyone is. Consider, the _only_ thing that distinguishes the litecoin blockchain from the bitcoin blockchain is a trivial bilateral hardfork. When litecoin came into being and you were running Bitcoin instead of it-- were you incurring a huge loss? No. From the perspective of the non-upgraded nodes, the parties with the mutilated protocol simply do not exist. Due to being bilateral, the same is true in the other direction. But none of this creates automatic winners or losers. And in all hardfork scenarios there is plenty of opportunity for everyone to be a loser. |
|
|
|
Since the integral of 1/x diverges at infinity, any attacker, even with an arbitrarily small fraction of the total hash rate, will almost certainly eventually overtake the network.
Yup. To be more specific: An attacker with a constant fraction (like 0.01%) of the network hashpower, who starts attacks and keeps up their losing attack forever, constantly adjusting timestamps to make their difficulty go up as fast as possible, _where the network hashrate (and the attacker's) increases exponentially_ overtakes with finite non-zero probability, and thus eventually overtakes. This can be intuitively understood by observing that given exponential growth in rate the total work in history is just some large finite portion of the attacker's current hashrate... and the attacker has some low but finite odds of reaching any possible luck level. If you do the math however, for any remotely reasonable choice of numbers the time the attacker must persist before they have a 50% chance of overtaking the results end up being insanely long, thousands and thousands of years-- to which you can reasonable answer "nodes shouldn't reorg a thousand years of blocks from their own timeline"-- making the attack pretty pointless. (just a brief dos attack on new systems joining the network-- until someone adds the one line of code blacklist to kill that specific attack chain. ... so N-thousand years of work that could have spent mining honestly, twarted by one line of code and achieving only an attack on a few new nodes joining the network). This also doesn't work if hashrate isn't growing exponentially (with any exponent) for everyone. Moore's law is not a physical law, it's an observation. Hashrates will stop growing at some point or another. |
|
|
|
I disagree with the assertion that "the only source of value difference between coins in the two networks is the friction related to the technical operation of the peg".
One could make the argument that another important source of value difference is the degree to which people are willing to hold either currency.
They aren't separate currencies. If you have 100 BTC in a sidechain and would prefer to have BTC in the parent chain, you simply move it. No third party or exchange is involved, only the fees and delays associated with making a transaction. If I created a peg while the Ethereum price was high, pegging BTC to Ethereum at the pre-DAO rate,
This doesn't make any sense at all: you cannot 2wp ethereum to BTC: they are separate currencies; with their own issuance and supply. Trade between them requires counterparties and cannot be guaranteed to be available at any particular exchange rate. |
|
|
|
|
The exchange rate is fixed because _every_ sidechain coin is backed by a fixed amount of coin in the parent chain with a fixed, programmed, and mechanically fulfilled guaranteed delivery.
This is unlike foreign currency, but like USD in your pocket vs USD in paypal (but without the custodial risk). Anyone with a coin in either can effectively move their coin into the other at any time using the peg mechanism. With a foreign currency there are separate independent supplies of the currency and no guaranteed exchange.
The only source of value difference between coins in the two networks is the friction related to the technical operation of the peg (the time preference and transfer costs, relative to the differential demand).
|
|
|
|
|
You have txindex enabled-- that severely harms performance, there are just so many transactions in the history that the performance isn't great.
Without txindex, and the dbcache turned up enough-- it will manage to complete a full sync without doing any writes other than the block/undo files.
The reason you see writes at start is leveldb will recompact its logs at start, so that is expected.
No doubt there is potential for improvement here, but the level of write amplification you see isn't unexpected. Bitcoin transactions are effectively a highly compressed format. There is a lot of work involved in synchronization.
|
|
|
|
Dear Greg, it seems you've missed a part of the protocol. Let me provide a quick description of Rollerchain, more precisely, modifications from the Bitcoin.
1. We authenticate the state and include root value into a blockheader. It is an old idea yes, and already implemented in Ethereum (and some other coins) as mentioned in the paper.
2. We then modify a Proof-of-Work function. A miner chooses "k" state snapshot versions out of last "n" a (sufficiently large) network stores collectively. In order to generate a block miner needs to provide proofs of possession for the state snapshots. On a new block arrival a miner updates k+1 states, not one, so full blocks (since minimal value in "k") are also needed.
Thus miners store a distributed database of last "n" full blocks AND state snapshots getting rewards for that activity. A new node could download not just a last snapshot, but from "n" blocks ago (or from somewhere in between). So it is not needed to "strongly trust the hashpower", but "hashpower" and also up to "n" last full blocks("n" considered to be >> than a deepest fork possible, say, 5000-10000 for Bitcoin) . And this is not about SPV, but about getting fullnode-going-from-genesis security(with probability of divergence going down exponentially with "n", see Theorem 2). Full blocks not needed in order to mine could be removed by all the nodes.
If you have concerns about this scheme please let me know, and I will try to formalize/address them.
Authenticated state root in a block header could be useful anyway for better SPVs. On efficient implementation, we're now working on that along with benchmarking. Let's see how it goes.
P.S. However, as PoW function modification is needed it is unlikely Bitcoin can go this way(miners will not throw away their ASICs).
I did not miss this. But unless I am misunderstanding you, you appear to be conflating two orthogonal changes. One is the change to the POW which requires the miner to show possession of state snapshot data. This does nothing to assure users that the data is correct. It ~may~ increase the odds there are multiple copies of it (though unless I misunderstand it-- your design is trivially delegatable so long as the miners are willing to trust the party storing the data until their coins mature, which users of mining pools already do almost ubiquitously). The other is that you begin nodes from a state snapshot, not at the tip, but at some point somewhat back. This is also taught in in the citations I provided above. This also does not prove that the state is correct, in fact it provides no evidence at all that the state is correct except under a strong assumption. Instead, participants hope that the state is correct without checking under a strong assumption that the majority hashpower would not extend a chain with invalid state updates. This is the SPV security assumption. It is different and weaker than the normal Bitcoin behavior, trusting a majority hashpower for the soundness of state updates and not merely their sequencing. In practice it is not sufficient to simply take such a strong assumption and not question it's validity-- normally the SPV hashpower assumption is justified by the widespread and economically significant use of full nodes which will not be deceived by dishonest miners; but with full nodes also making a SPV assumption for blocks away from the tip, this argument becomes circular. The SPV assumption is especially concerning because we have discovered that miners have begun bypassing validation themselves in order to mitigate the negative effects of larger amounts of transaction data on propagation. State sampling proof of work has been argued as a potential improvement for this particular issue, but proposals so far have worsened the generation of progress in the mining function (as the last miner to create a block has a state update advantage) and they still leave plenty of opportunity to optimize by shortcutting the parts of validation that the state updates do not expose. Perhaps it would be revealing to answer a question: You are a new node joining the network. I am part of an attacking consortium which has, for several months, had a super majority hashpower at my disposal. Can I cause you to accept a chain extending the chain from no further than a few months back, otherwise compatible with a 'honest chain' (if it existed)-- meaning containing all the same transactions and ownership except as mentioned-- where I instead have a million extra BTC reassigned from the earliest blocks? |
|
|
|
|
Centralized fake cryptocurrency is centralized fake cryptocurrency... and belongs in the altcoin section.
|
|
|
|
In the first place, there is no rationale to store 7 years of history for synced nodes. But how a new node could get into network if all the fullnodes have thrown away all the blocks(except last few ones to handle possible rollbacks)? Bitcoin has no answer for that. I've developed a proposal to fix the issue and solve some important questions towards better scalability. The paper is just uploaded http://arxiv.org/abs/1603.07926 . I would be happy to get feedback. This paper is a bit of a disappointment, sad to say. First-- it makes a number of false claims about the capabilities of the existing Bitcoin system, e.g. "To be rational it is needed to switch to an implementation of the Bitcoin protocol which does not hold the unnecessary data (such an implementation of a full node does not exist to the best of our knowledge)." The whole reason that Bitcoin has state snapshots, as described in the paper, was because they were introduced to enable strong pruning (a more limited version is described in section 7 of the Bitcoin whitepaper). Bitcoin has supported operating in a pruned fashion for _years_. The primary suggestion the paper is making is to bootstrap nodes from state snapshots. The paper describes this as "trustless" but it is _not_, rather it makes the same strong assumption of hashpower honesty that SPV (lite wallet nodes do), implicitly trusting the history of the longest chain to be faithful. This is not a new idea, its expression spans at least back to 2011: https://bitcointalk.org/index.php?topic=21995.0and https://en.bitcoin.it/wiki/User:DiThi/MTUT(as is using random tests for data in the mining process,-- though the scheme you suggest is fully delegatable, so long as the miner doesn't mind giving temporary custody of his income to the centralized party holding the world's only copy of the blockchain. ) The state commitment proposals face a couple challenges, one is that if you are willing to strongly trust the hashpower-- then why not use the vastly more efficient SPV mode? The other is that the initial efforts to implement continual state commitments found that the overhead (primarily IO) of maintaining them multiplied the full node operating costs at runtime by several fold. The costs have made what would otherwise be another option for client security less attractive, supporting a more niche security model would be fine if it were inexpensive. Alternative designs like mimblewimble try to make bootstrapping more efficient without adding a new form of strong trust towards miners. |
|
|
|
Why isn't that done yet? Because until very recently it was burred in the profiles; optimization elsewhere has exposed it. Any such change has to be done with great care because of consensus consistency of course-- and optimized hash functions for non-parallel use are not ~THAT~ much faster: SHA256_avx,255,0.0039705,0.0040791,0.00397483 SHA256_basic,175,0.00599706,0.00610304,0.00599851 SHA256_rorx,319,0.00334549,0.00345182,0.00334802 SHA256_rorx_x8ms,319,0.00328481,0.00339317,0.00328667 SHA256_sse4,255,0.00395852,0.00404716,0.00396052 basic is the plain code we have today, the fastest in that test (rorx_x8ms) is only 1.825x faster. https://github.com/laanwj/bitcoin/tree/2016_05_sha256_accelI expect this to go into 0.14 sometime relatively soon. Use of a 4-way implementation would speed it up further, but making good use of 4-way sha2 is technically somewhat difficult-- not just a drop in change, and there are only a few places where it can really be used at all. Wladimir has done similar testing for the CRC32c, https://github.com/laanwj/bitcoin/commit/431c1b987b34589f32f4c2d0ee0f2571ba70e349in all cases, these higher performance versions require use of special instruction sets that aren't available on all systems so additional code is needed for runtime autodetection. Not a big deal, but part of the reason that it wasn't magically changed the moment it was the highest point in the profile. |
|
|
|
The gist of an earlier comment of yours seemed to be: "writing smart contracts is inherently hard and unnatural, so it's fine if the scripting language is hard to understand." I just don't see how one aspect of writing contracts being hard (getting the logic right) implies that it would be better for other aspects to be harder than they need to be.
If a declarative version of Bitcoin script made mistakes less likely, what is the downside? Are you worried about newbs who just learned a bit of javascript thinking they can write secure smart contracts just because Bitcoin script v2 might look a bit more like javascript? So the fact that current script looks intimidating is actually good? If so would it have been even better if Satoshi made all op codes of the form OP_XYZ where X, Y, and Z were digits? And maybe disallowed spaces when not including them would still be unambiguous? That would certainly reinforce in people's mind that writing Bitcoin script is tricky.
You misunderstood what I was saying. A declarative model doesn't reflect the reality of these systems well. It is easier to get started, but hard to do things right, and very hard or impossible to to be confident that you got things right when you did. A more functional model reflects the reality of the systems better, while also providing powerful scaling and analysis benefits. I believe it is possible to construct systems which are harder to get started, but once you get something working its very likely to get things right, and hard but far from impossible to _prove_ you're achieving the properties that you set out to achieve. I haven't proven that better can be done, yet (unless you count Bitcoin script)-- but what DAO/ETH seem to be proving is that at least that design is too dangerous to be used-- when their highest profile contract, reviewed by the designers of the system/language, got robbed blind by a rather simple vulnerability. |
|
|
|
The only purpose of it is bitcoin core specific software testing, it's effectively free to compute while returning those other statistics, and it allows rapid isolation of suspected database corruption or inconsistency. The structure of the hashing is not well suited to other applications. and xor all the hashes together to get the final value.
Congrats, you win today's failed cryptography trophy. That kind of structure is trivially to second preimage attacks using wagners algorithm for solutions to the subset sum problem. Order independent accumulators are a tricky subject, the only that I'm aware of that have any real argument for security have huge hashes and are very slow. The data hashed here is also _highly_ implementation specific and subject to change in any new version without warning. |
|
|
|
Your project contains the old centralized "alert" system previously copied from upstream Bitcoin. This system lets the holders of a private key send messages to be displayed in the error field. Because of its limited utility, potential for abuse, known disclosure of the key to at least one untrustworthy party (and is believed to be compromised), and frequent use to justify other centralizing features this system has long been deactivated (and now is completely removed) upstream. I would recommend you remove this system by adopting this code from upstream: https://github.com/bitcoin/bitcoin/pull/7692 or the parallel PR in bitcoin xt, https://github.com/bitcoinxt/bitcoinxt/pull/150 |
|
|
|
CT for solvency proofs is well known, I posted about it here (someplace) on the liabilities side some time ago. Whats even more interesting is that private assets side is also possible in Bitcoin today: http://crypto.stanford.edu/~dabo/pubs/abstracts/provisions.htmlUnfortunately there is relatively little interest from most exchanges in these tools. |
|
|
|
There are several companies performing sybil attacks on the network. They connect to every node they can reach (the 8 limit is for _outbound_ connections) and also listening to connections, running many fake nodes so that it is likely that you will connect to them. They also monitor the timing of addr messages to attempt to infer which addresses are connected to the nodes they are connected to. By monitoring the timing of transaction announcements they can learn a lot about transaction origins, especially if addresses are reused. As far as i understand, it's even a bad idear to use bitcoin and tor:
This is highly misleading. The claim is that attackers can DOS attack tor exits, causing a tor using Bitcoin user to potentially need to stop using Tor during a DOS attack. This is untrue because normally with tor Bitcoin nodes are connecting to other bitcoin nodes as hidden services, no exit is involved... and not very relevant because, "maybe tor gets DOS attacked and you need to either wait or switch it off" is in no way worse than never using tor in the first place. |
|
|
|
|
It didn't start with them. It started with people pushing for a hardfork in Bitcoin making the factually unsupported claim that whatever "the most" hashpower says is what happens.
The fact that Bitcoin software has _never_ worked like that (nor any altcoin that I'm aware of) hasn't phased them. Ethereum has just been running what that misunderstanding. It'll be pretty interesting to see what happens when ETC ends up with more hashpower.
|
|
|
|
|
Show Posts
