Ok, so lets try this again with the right numbers, and some background explanation: The question I was asking was: do the users of bitcoin collectively posses enough raw hashing power in their CPUs to rival the miners? Assuming we change bitcoin to force users to send a PoW with their transaction which takes them 1 second to compute on a 10 Mh/s CPU, combining this with the transaction throughput the network currently has, what would their hashing power be? So, we've got (assuming 5 transactions per second) 10 Mh/s * 5 tps = 50 Mh/s Comparing to the miners 7,983,858,406,000 Mh/s, we end up with users currently having 0.000000000626% of the miners hashing power, if we force them to send a 1s PoW with each transaction. This is obviously completely and totally insignificant, and not worth trying to capture to improve chain security. So, what would it take for the users to rival the miners? At 10 Mh/s, how many tps do we need? 7,983,858,406,000 / (50 / 5) = 798,385,840,600 tps Mmmm, not likely, so instead how many seconds would we need to force users to spend computing a PoW at 5 tps? 7,983,858,406,000 / 50 = 159,677,168,120 seconds or 5063 years per transaction. |
|
|
|
I'm not sure where you got your information from, but you seem to have quite a few things wrong, and some other things that simply don't make sense (perhaps you can explain better?). Recalling that the difficulty is the expected number of hashes taken to solve a block,
It is not. My bad. I had been assuming (16 bit hashing analogue to skip writing all the characters): difficulty = diff_1 / target , so target = diff_1 / difficulty , so for a 16 bit hash, and difficulty 1 it would be target = 0xffff / 1 = 0xffff would result in a single hash being lower than the target, hence my reasoning. Probably should have looked up the actual values. |
|
|
|
|
I was just doing some back-of-a-napkin style calculations to figure out the hashing power of the users of bitcoin, and whether it would even be worth looking into trying to harness it in some way.
Recalling that the difficulty is the expected number of hashes taken to solve a block, with current difficulty at 3007383866429, and assuming we have normal CPUs with an average of 10Mh/s (this may be optimistic), and assuming sending a transaction took 1 second of hashing, we'd have enough hash power in plain transaction sending to rival a 1% hash-power miner, if the network was sending 5 transactions per second*.
Is this significant enough to try and capture? Is it even possible to do so?
* 3007383866429 = 3007383 mega hashes
3007383 / 10 Mh/s = 300738 seconds to solve a block in 10 minutes
300738 / 600 seconds in 10 minutes = 500 tps for 100% network hash power
|
|
|
|
You just mentioned what Monero can do. But you need to do proper full nodes configuration and use secure connection for maximum privacy/anonymity.
Monero has made good strides towards proper privacy. I thought there were some lingering questions around the ring signatures, though? Can the receiver of a private transaction prove a link to the sender? That's another biggy. |
|
|
|
|
I've skimmed it, but something strikes as strange. How can it be trustless when the backing is physical assets that need to be managed?
In addition, housing the futures part of the protocol in a data center isn't terribly decentralised?
|
|
|
|
Without a whitepaper, it's impossible to say. But the lack thereof tells us something about them - i.e they didn't peer review, which is a bad sign. |
|
|
|
|
I wanna see a P/L graph for the previous year of your firm's activities... as should any investor in such a fund.
|
|
|
|
|
Privacy/anonymity consists of:
A. unlinkability (can't tell two transactions are to the same recipient): stealth (or just not reusing addresses)
B. untraceability (can't trace paths between tranasctions): ring signatures (or coinjoin, coinswap, though with many complications and hazards, etc.)
C. content privacy (can't see amount being spent): CT (or limited ambiguity of which outputs are change)
I'm not sure if there is any existing crypto which satisfies all three of these requirements.
|
|
|
|
Just „thinking out,loud“: could you use a POS system? or a IOTA like confirmation process, where each participant needs to do some work? To avoid spam mails, the idea was used in the very beginning.
Not sure, how far you are in your project, and if such changes would be meaningful...
I wrote a paper about a system which is similar to IOTA without the centralisation... but it's a new crypto, and not trivial to implement: https://bitcointalk.org/index.php?topic=1992827.msg19843771#msg19843771 |
|
|
|
Hi,
I just want to float a crazy idea that occured to me a few days ago. Don't think I am the only one around here thinking about this matter (and I am lazy searching the forum for a similar thread).
What is Bitmain developing other than ASICs? SOPHON, their deep learning AI.
Now imagine the incredibly wast amount of computing power now already connected to all the mining pools in the world being suddenly somehow switched (or waking up) forming a consious AI.
Any reactions?
Totally possible. Look for a thread on here about PoW mining using conway's game of life. edit: here you go: https://bitcointalk.org/index.php?topic=2977765.0 |
|
|
|
There are emerging cryptocoins which don't rely on the 'old' blockchain technology. The most known of them are IOTA and NANO (raiblocks).
I have never used these coins so far, but their developers state these coins can provide a lot of improvements and better features than traditional blockchain-based cryptocoins like Bitcoin. For example, faster and cheaper transactions, less energy consumption and so on. So do you think blockchain-based cryptocoins are doomed and the future will be favorable to these emerging technologies?
Neither Iota, or raiblocks have decent enough security models to challenge bitcoin. Iota is completely centralised and raiblocks cannot withstand bootstrap poisoning. The true successor to bitcoin is yet to emerge, and the technology isn't quite there at the moment. It's an unsolved problem. |
|
|
|
|
As someone who has done this in the past, I'd have to say you need a team, more than anything else. Even if you are the most skilled bitcoin, web front and back end developer in the world, you will still need a team to handle the day to day running of the thing.
Support requests are an utter nightmare.
On top of that you DO need to have cutting edge bitcoin security knowledge, or it will get hacked just when it gets off its feet enough so that people start taking notice, and then you'll be in some serious trouble.
You'll need to hire proper bitcoin pen-testing hackers on a regular basis to carry out white hat attacks on the site.
On top of that, you'll need to have top-notch back-end systems architecture guys on the project to handle scaling, as the adoption curve for these things is exponential, so if you have bad architecture, you'll be screwed because it won't scale.
To summarise, this is not a simple project, in fact, probably one of the most challenging projects you could possibly undertake.
There is a reason Poloniex just sold for $400M. It's not easy to do.
Cheers, Paul.
|
|
|
|
ironic that Proof of Anti-stake may work
the idea is, that user destroys it's coins and by doing so confirms a block
Doesn't work because to burn stake you must send a transaction, and you cannot come to a consensus on the current set of valid transactions by sending more transactions, it's a chicken and egg problem. I did some analysis on it a while back, and long story short, it degenerates into PoS. |
|
|
|
Agree that the paper is hard to read, and that's partially unavoidable due to the complexity of the algorithm, and how all the parts are actually needed to work together. What exactly would you say is babble?
We haven't seen anyone understand the way the system works in under a day (including any of us), and you started making comments about an hour after we posted, so pretty sure you just skimmed through the paper.
It's understandable that you may not have the time to do a rigorous analysis, we're just some guys asking for advice on a forum, but what's the point in asking for attack vectors of a thing you don't understand?
We've actually pointed you to page 31 in a previous post, where we explicitly state that a majority of the network needs to agree on the state within a certain number of rounds, or else it's considered void, penalizing nodes essentially. Can you say why this doesn't say that consensus will freeze in the worst case?
There are a lot of other bits of analysis we could have added to the paper, but it would have made it over 100 pages long, without anything essential to understanding the core, since we've seen these naturally clear-up for the people that understood the core protocol, realizing that those issues apply to blockchain-based consensus and not to our algorithm.
I know you may be used to people posting crap algorithm that are easily dismissed by showing their obvious holes, and it's understandable why you'd fire some automatic arguments, they're usually valid. Still, I hope you can see that's not the case with us and that we're working on different assumptions than blockchain consensus developers.
Most of the time spent in the paper is talking about trivial things. Consensus is the hard bit, IMO the entire paper should be about that, the possible attack vectors, how it responds etc. You've made a lot of wild claims in there, which rang alarm bells for me, such as solving the NaS problem and even the claim about byzantine tolerance is hard to verify because of the way the paper is written. Take a look at Ripple's last ledge close paper; that is clear and concise, and your design shares a lot of commonalities with that. |
|
|
|
The problem that you're facing is that of network partition combined with the fact that you allow a subset of lockers to participate in the sequence of processes that finalise the state.
You can end up with a fork if you allow a subset of all allocated lockers to finalise the state, due to network partition. If you require a majority to participate, you will get a stalled consensus until the partition resolves itself.
Nothing the lockers say finalizes the state. A locker signed transaction needs to be confirmed by a majority of nodes to be accepted. Like previously stated, consensus is delayed until approved by the majority, even with the risk of voiding the round. The fact that you keep mentioning a fork means that you're not very clear on how the algorithm works. Did you understand this from the consensus section? It could be the paper is not clear on it, but please try reading it again. To be honest, the paper very hard to read. A lot of babble, and hardly anything about the attack vectors, or failure modes. I'd like to see a description of how the consensus will freeze in the worst case, rather than forking in the case of a network partition, for example. |
|
|
|
In the case you presented, if 10/20 lockers appear offline and later they try to broadcast the transactions for which they were the assigned lockers, the other nodes would simply ignore those transactions. Honest nodes always ignore transactions that were signed more than 2 rounds in the past. But indeed, there could be a conflict if the lockers come back online in the middle of the following round. After the transaction broadcasting phase follows the sync & commitment. During this second phase nodes solve any kind of inconsistencies, e.g. revert double spends. Only after syncing there is a commitment vote on the global state some X rounds in the past. Anything that happened during those last X rounds is still subject to change through the sync process. A fork can only happen if the network doesn't agree on the commitment state. As for the propagation times, check out this screenshot from the paper you linked:  . Our transactions currently have ~300 bytes, that's why the propagation times of Blockchain based protocols don't apply to us. The problem that you're facing is that of network partition combined with the fact that you allow a subset of lockers to participate in the sequence of processes that finalise the state. You can end up with a fork if you allow a subset of all allocated lockers to finalise the state, due to network partition. If you require a majority to participate, you will get a stalled consensus until the partition resolves itself. |
|
|
|
We're trying to prove in the paper that actually there's no such case where a fork happens involuntarily.
That's the purpose of the synchronization phase, to make sure that forks happen only when nodes explicitly want them to happen. Nodes will keep making round proposals until they're sure that they've got a consensus. If nodes can't agree within a certain number of rounds, it's actually in their interest just to void the round.
If you're aware of a specific case when an involuntary fork can happen, please let us know.
Do you have any reference for the 15s gossip time? All of our testing showed much lower numbers in the order of a few seconds at most, if all you needed to gossip what in the order of a few hundred bytes. Blocks are much larger though, and that's why I'd imagine a disparity could come from.
What about in the case I've just presented, though? 10/20 lockers appear off-line, but really they're just delayed such that the round closes with the first 10/20, but then the other 10/20 also publish a round close for the same round, leading to a fork? Here's your reference for propagation times: http://www.tik.ee.ethz.ch/file/49318d3f56c1d525aabf7fda78b23fc0/P2P2013_041.pdf |
|
|
|
There's no way to create a fork on those transactions, since the majority of the network needs to receive them in the next round at most, to confirm them. Think of lockers as a pre-validation step, gatekeeper to the system if you will. Since those transactions were not confirmed by a majority of the network, that means that those transactions will never be accepted, and everyone the applied them will undo them.
Between the time a transaction is signed by a locker and confirmed by the network, it's essentially pending. We expect running a full node to be something that only servers with decent processing power and good internet should do, so delays are rare. The latency between almost any pair of servers with decent internet in the world is less than 300ms. Even if delays happen between some pairs of nodes, there would have to be a global internet problem in order for a majority of the network to have these issues.
In essence, we want to optimize the system as much as possible for the average case, while still being robust for any worse case.
I understand that, but what about the round itself? Surely there's a case where a given round can be submitted with a separate set of transactions, leading to a fork? Btw, worldwide network propagation using gossip is on average 15s, that's why ETH's block time is around there. |
|
|
|
Our entire algorithm is focused around the idea that independent transactions can be treated independently. So in that round all the other transactions will be accepted, except those that were performed on accounts which had unresponsive lockers.
Ok, so, 10/20 go through in this round. ...What happens when the 10 which were offline, weren't actually offline at all, but just delayed due to latency and they produce a fork of the just submitted round with the last 10/20 transaction in it? |
|
|
|
There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.
What happens when lockers aren't available to sign for their allotted accounts? Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline? The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network. So that round closes empty, or we get 10/20 transactions in the round? |
|
|
|
|
Show Posts
