I'm glad you're skeptical, there are a lot of people with incorrect ideas out there and I don't want to propagate another.

One thing I think is worth pointing out is the focus on decreasing the number of consensuses that need to be agreed on. With existing cryptos every transaction for everyone is subject to consensus and as you correctly pointed out, consensus is hard.

The attempt was to arrange the protocol in a way where consensus is almost never needed.   If we can change the system so we need to do the hard problem a lot less, we've hit scalability.  In fact it's arranged so only bad actors are punished by the slow path of consensus and I think that's the value.

Thanks for the ongoing critique guys, I appreciate smart people working to break thing

These are great points. One thing nodes will be able to do is track the total weight of votes that have been received for a forked block. If this is noticeably lower than the total supply indicating disconnection of representatives, nodes can leave forked sends unreceived until they're satisfied the block has enough integrity for them to accept it.  This would be analogous to observing hash rate significantly dropping indicating miners being disconnected. If representatives are being DDOSed they can choose to not touch forks so well behaved accounts have no problems and accounts generating forks are unable to transact.  

If the network gets partitioned I think the problem would be equivalent to if the Bitcoin network somehow got partitioned. The partitioned segments would be continuing on their own sections until the networks merge and one side gets evicted. One thing to notice though is all it takes is one node connected to both partitions for them to begin to merge.

It would be incredibly hard though hypothetically feasible for the network to be perfectly disjointly partitioned and one fork to be placed in exactly one partition. In this case we'd have to fall back on observing vote totals dropping indicating massive disconnection.

Heuristic suggestions are welcomed!

It's recommended that people pick reliable and diverse representatives, universities, enthusiast groups, corporations, placed on platforms designed to deal with all the problems any popular network service needs to deal with.

It's a good observation. The "accounts involved" in the context you described would roll back the send to Charlie in bob's chain as well as the receive from Alice in bob's chain. And finally the losing fork in Alice's chain.

Two things to notice here is that all the thousands of other accounts uninvolved aren't affected at all, this is the advantage of the individual chains.

The other thing to notice is bob could guard against having his chain rolled back by allowing time for him to observe possible forks. How long does he have to wait?  About one network propagation period because by then, someone somewhere would have rebroadcast the block and if they haven't, the fork will have a very low vote percentage because everyone's already agreed on the first block.

The worst case scenario for forks is creating n forks and distributing it to n representatives with close to equal vote strength simultaneously. Then bob should wait until the vote total is statistically definitive in his direction, >95% or a heuristic before accepting it.

Bob can still continue accepting from non-forks and sending to others even if he is named as the recipient of a forked block. Bob could also choose to never accept the forked block if he wanted.

I think you're describing it accurately.   Any account can be a representative and accounts can change their rep at any time.   If accounts named each other as you described they would have vote weight as you described.

*edit* I think the description of representation was backwards. If Alice and bob name Tom as their rep, Tom has all the vote strength and Alice and bob have none even though Alice and bob have a balance. Representation is giving weight equal to your balance.

One thing to note is that voting only happens if there is a signed conflict so the easiest way for your account to not be susceptible to collusive votes is to not sign forks; only cheaters are voted on. Collusion of voting is analogous to collusion of miners in Bitcoin. The difference is how much does it cost. With mining the cost of getting >50% strength is the capital investment in hardware to mine that fast. With voting collusion the cost of getting >50% control is the market cap of the entire currency.  Market cap of currency > capital investment of mining hardware and it isn't susceptible to technology advances e.g. Gpu -> asic so I feel this is a stronger guarantee than mining.

To prevent a Sybil attack, votes are weighted based on account balance, the only way to have a larger vote is to have more value stored in the the protocol. People voting against the protocol are voting to destroy the value they hold in the network I.e. Burning your own money.

Rep in this context is representative. The concept is to address your good second point, votes flying around the network. Each account can designate another account as their representative and the rep can vote with but not spend with their balance weight. Also note that voting is not initiated unless a fork is actually observed.

Nodes not flipping their votes is analogous to Bitcoin nodes not taking the longest branch, it's not really Bitcoin anymore. Nodes trying to publish blocks from orphaned forks will be rejected because the previous hash value is not a valid block and receivers won't accept these blocks because then their chain would be invalid.

Thanks for taking a second look guys, I took your questions to heart and thought the best way to explain was to create a couple graphics of how things work.



The transaction animation shows the typical, non-attack scenario how transfer of balances occurs.  The contents of these blocks are almost exactly how it's done in the code, minus signatures.

The animation is:
1) Create send block linking previous head block and with a new account balance < old balance
2) Create receive block linking previous head and linking source block ensuring source hasn't been received already.



The fork animation shows what most seem to be interested in, consensus of bad-actors.
1) One or more signed blocks pointing to the same previous blocks are created and distributed to different nodes in the network
2) Nodes redistribute blocks they've just seen and soon everyone in the network has observed a fork
3) Nodes initiate voting by broadcasting their vote and tallying the votes of others
4) Nodes who are voting for a block with <50% of the tally change their vote
5) Consensus is achieved after a few rounds of voting

Going with the theme of efficiency and scalability we tried to making resolution as easy and efficient as possible.  We notice people marked as a receiver can keep their own chain separate from a bad actor trying to send forks to them, this way only the bad actor is stalled and the receiver can wait out the resolution until it's definitive.  This goes to the scalability where we stall only the people doing things the wrong way.

It's important to note the time window for a fork block getting anything other than a 0% vote is less than one network propagation interval.  Nodes in RaiBlocks rebroadcast their transactions so once everyone has received a copy, any new fork will get no votes.

I added the animations to the main description pages in the wiki
https://github.com/clemahieu/raiblocks/wiki/Block-lattice
https://github.com/clemahieu/raiblocks/wiki/Double-spending-and-confirmation

I called parts of it a block chain since the send/receive blocks contain a hash of the previous block and it has a one-follows-another order.  It's different than other cryptos in that one block is one transaction, a send or a receive, where others contain many transactions.

Thanks for spending the time you did looking at it, sorry about the lack of comments that's admittedly in poor style.

These differ from off-chain transactions in that each chain is replicated to all peers so all account actions are observed and validated by everyone.  Rather than packing all transactions in to a single chain, all transactions for a single account are in a single chain.

On the double spending front, since all blocks for each chain are replicated to everyone, nodes can ask and publish their view of signed Y-follows-X blocks.  If anyone instead sees a signed Z-follows-X block this is a fork and needs resolution.  Unlike monolithic blockchains, a fork in this system only affects a single account instead of everyone, again working toward scalability where we don't stall everyone because one section has an issue.

Resolution is done through a weighted vote system where losing blocks and dependents are rolled back.  Senders can be sure they're not receiving a double spend by observing votes and tallying them, if they observe no forks or a resolved fork they can safely accept the transaction in to their chain. Notice though that resolution is never needed in the normal, well-behaved case.  Forks only happen with signed, conflicting blocks; only accounts that are misbehaving by intentionally creating forks will every be put up for resolution.

Let me know if any of what I wrote doesn't make sense.

I’m hoping people would have some feedback on a project I’ve been working on.  The issue I was trying to solve was scalability: transactions per second and confirmation speed.  What I ended up with is a system similar to side-chains except it’s taken to the extreme where each account manages its own chain and all chains are replicated to all nodes.  What happens with this system is there are virtually no distributed agreements because each account has authoritative control over its own chain.  With the account owner having authoritative control over their own chain, transactions don’t need to be mined for validity so confirmation time drops to near zero and transactions speed is as fast as they can be published.

I was looking for some comments, good, bad, indifferent on what people think.

For gritty details I did a writeup here https://github.com/clemahieu/raiblocks/wiki/Block-lattice which includes information about double-spending

It looks like an unhandled exception due to an unexpected type number.  It could be due to corrupt data on the disk or in a really bad case, corrupt data on the network.  I say really bad because if the client doesn't handle this correctly, someone could DoS the network by sending invalid data to peers.

Definitely contact the developers.

What would you recommend people do to avoid being in the same situation?

0% time for everything?  Are you running the program inside a virtual machine?  Virtual machines don't have profiling hardware so they'll ruin gprof results, otherwise I haven't seen that issue.

You should first restrict your work to only the directory where you unzipped the code you're compiling.  Searching the entire c: drive will find other projects that use CMake which many do.  I should point out that the '/GS=1024' was made up because of the limited information, there are hundreds of command line arguments to visual studio and the problem could be with any.

Make sure you are following the build instructions exactly, otherwise you might have to ask the people who make the code to help or fix the issues.

Best of luck!

This is a fairly small amount of information to go on.  It looks like you're compiling on windows and Visual Studio is giving you an error saying it doesn't understand something given to it on the command line.

Invalid numeric argument '/Wextra' sounds like it's trying to interpret '/Wextra' as an argument to something but this is actually an argument all by itself.

If I were to guess I'd say there's an argument to the left of this on the command line, which has been improperly filled in by the build script, something like "/Gs= /Wextra" where /Gs is expecting a number like "/GS=1024 /Wextra"

Notice how there should be a number there '1024' but if there isn't it'll think the next thing on the command line is a number.

It's not much of an insight but "method not found" errors are automatically or programmatically generated responses because it doesn't know the commands you gave it.  I noticed you said "a scrypt coin" which omits which code base you used.  Code bases can claim to be "scrypt coin"s but not implement all functions in other scrypt coins which is probably what you're running in to.

Have you profiled the application?  Where's the CPU time being spent?  It's entirely possible the algorithm to calculate PoS is broken in a way that still consumes all the CPU time.

It's true PoS should result in lower CPU overhead but any algorithm anywhere, if improperly implemented, can give horrible efficiency.

It doesn't seem technically feasible regardless of philosophical goals.  Figuring out if someone on the web is a human or a bot is hard enough, I haven't heard of a proposed scheme to figure out if someone's a unique human.

On their site it looks like they're distributing via an email address and one email address does not map to one human.  I couldn't find any technical details about how they plan to distribute.

Edit:
It looks like they also uniquely map to social media accounts which leaves out a large portion of people who don't have them and doesn't address the difficulty of finding shell social media accounts.