Now that we have the new genesis block websites, these inconsistencies no longer matter.   

This bounty is closed... we are removing angelshares.info from our website as they have not maintained the site properly.

Where can I find info on the new genesis block websites?

A quick attack that is over within a few blocks is not even a viable attack with the current market structure.   Presumably no one would even know which nodes are publishing the market making transactions and of course there is no such thing as an 'undesirable transaction'.

Once again, I am positing an attacker with a large number of nodes at his disposal.  Say half the nodes on the network.  And they all function normally until the attack occurs.  Such an attacker would be able to figure out who is generating large numbers of transactions.  They would have plenty of time to study the market and figure it out before attacking.

What I am calling "Undesirable transactions" are transactions that are forced through the market by bad actors at a time when liquidity has been artificially limited by those same bad actors, and which create values out of the desired norm, such as 1 BitUSD losing its peg to the USD.

Peers that propagate an invalid transaction are disconnected.

Immediately after the first invalid transaction?  What if they are disconnected but then immediately attempt to re-connect?  How long of a memory does it have?  Does it block based on IP or some other identifier?

I think there are plenty of ways to prevent network wide DOS attacks.   There could still be targeted attacks against specific nodes, but anyone who is in the business of making money on active trading would always act through proxies and keep their true server location hidden.

Of course, but if their proxies are knocked off somehow, then it could take a block or two before they establish new proxies and re-connect to the network.  I am suggesting a quick, targeted attack: DOS selected nodes, immediately slam the market, and have everything over within a couple of blocks.  (Block times are what, 1 or 2 minutes, IIRC?) The attack ends, but the blockchain is a couple blocks larger and filled with undesirable transactions.

DOS attacks are readily addressed.

So have they already been addressed, or is it on the to-do list?  Or on the "to think about later" list?

Is there a peer limit?  Is there a peer request rate limiter?  Does the peering mechanism have a counter to the old SYN flood attack? (whether actually based on actual TCP SYN, or the higher-level peering equivalents; I imagine there is a typical handshake "Hey I wanna peer!" "Ok let's do it" .... wait for acknowledgement.... wait some more.... wait how long?  Wait for how many new peers at one time?)

Couple of minor typos in GodsCreation's submission.... in the paragraph under the Angelshares heading: "crow sourcing", "prototos-hares" (if the hyphen remains after taking out the extra "to", it should read "proto-shares", not "protos-hares"), "bitcoind holders".  Just in case you print up another batch, or use it on the website.

It currently appears that angelshares.info is bizarrely out of sync with most information.  E.g. it is still showing $870 USD per BTC; 0.169 BTC per PTS; and apparently hugely underreported PTS donations per day.

Rolling back a block does more than just unwind the market, it unwinds all transfers.  Having to unwind the network is reacting too late...

I agree, but reacting late is what we all do when we find out that we're fallible.  We simply don't believe it until proven to be so.

It is kind of like the US Constitution containing provisions for it to be amended.  The Founders realized that the system would have unforeseen problems, and that the system therefore needed to have an internal process for changing itself.  Not a good idea to rely on revolutions acting outside the system; better for the system to allow change within itself.

--------

As a side note: any comments on the network security problem?  The network is only as secure as the least secure critical node (and there will be critical nodes).  Since we have no way of privileging critical nodes, the network is only as secure as the least secure node.  Yes, presumably people will add hardened networks, diversify their network locations, etc. over time.  But it will take a while before it reaches that point.

Until that time, maybe there won't be any attacks like I'm outlining, because there won't be enough value in the system to make it worthwhile.  And once the system does reach that valuable level, all critical nodes will pay to provide their own security.  Still, the threat exists, and the threat is not just to individual nodes, but to the network as a whole; especially for pegged assets such as BitUSD.  The thought that liquidity could be forced off the network is a scary one.  I think that some level of IP obfuscation would be a good idea.  Maybe not initially, and maybe not in every DAC; but eventually, and in at least some DACs.

--------

As another thought, what if somebody seeded the network with bad nodes?  Create a million node botnet, and have these nodes simply drop all transactions instead of propagating them correctly.  Or, perhaps worse, propagate certain transactions while dropping others entirely.  If these bad nodes constituted a majority of the network (not the stake, but the network) then they could manipulate things fairly easily.  Of course these nodes would have a latent period of acting normally, until the owner flips the switch and starts dropping transactions in order to manipulate the market.

Perhaps an explicit network connection mapping mechanism could be tied to stake?  Sort of a matchmaking service for nodes to decide who gets to peer to whom.  Presumably a botnet attack with millions of nodes would have very little, or no, stake per node.  So make it so that those nodes can't connect directly to nodes with a large amount of stake; or only a limited number of them can.... for example purposes, say nodes can have stake of value from 0 to 10.  Say that a node with stake 10 has 10 allowed connections: 3 allotted to stakes in the range 6-10, 3 allotted to 3-5, and 4 allotted to 0-2.  So a node with stake 10 can never be "surrounded" with only nodes of stake 0, where all transactions initiated by the stake-10 node must be propagated through stake-0 nodes in order to reach the rest of the network.  So if someone created a million node botnet, all of those nodes would be able to join the network, but they would all be on the periphery of the network, and they could never penetrate deeply into the interstices where they could interrupt the communication from one critical node to another.

Of course, a node with high stake could still attempt something like this, but the good thing about this plan is that stake must be concentrated in order to reach the inner parts of the network, while large numbers of nodes are needed to carry out a dropped-transaction attack.  So the larger your number of nodes, the lower the stake per node, and the less ability to carry out an attack.

TL;DR: A proposal for the network to allow peers based on trust, where trust is based on stake, in order to prevent attacks by numerous nodes not propagating transactions.

DOS attacks / knocking nodes off the network

I am still concerned with DOS attacks on nodes.  We will have some number of nodes making automated trades all the time and acting as market-makers.  Their IP's will presumably be visible.  Those IP's can be DOS attacked with a high probability of success.  Professionally hosted servers with fast Ethernet speeds and robust firewalls can resist DOS, but most consumer-level nodes will not have this degree of protection.  I would feel wary of placing many orders knowing that I could be knocked off the network indefinitely and without notice.  Even if there are several hundred nodes acting as market makers, if a good chunk of them can be blocked from the network, then the depth of the market will drop dramatically.

IMO this is the greatest threat to the exchanges.  Wall Street exchanges have hardened, direct connections between nodes -- no connection to the outside Internet, or to any untrusted/unbonded entities.  Every node on those networks has a name, a face, and a federal EIN.  They can screw up and place wrong orders, but those orders can be tracked and cancelled if necessary by a central authority.

BTS XT has no limits to the number of connected nodes.  No node can ever be banned, because it can just change addresses and show up again anonymously.  Hundreds, thousands, even millions of nodes (botnets) can all connect and appear to be acting independently when they are actually under unified control.

I am unsure what can be done of this.  TOR-like obfuscation of IP's might be a good start.  This essentially consists of a routing table.  Each node can be connected to a maximum number of other nodes.  Base it on a logarithmic function of the total number of nodes in the network.  So if there are 20 nodes, each node can be connected to 5 other nodes.  If there are 20,000 nodes, each node can be connected to 50 other nodes.  Each node maintains a list of all other nodes, which are denoted by random addresses.  Node A knows that it can access Node B through IP address 9.9.9.9, but Node A has no idea whether Node B actually resides at 9.9.9.9, or if it is actually 20 levels of indirection behind 9.9.9.9. 

This way, all IP addresses are obscured; there may be a market maker on the network named BiaJ8asfl9, but it would take a lot of work to figure out its actual IP address.  It would not be impossible, since I could simply create 1 million new nodes, and have them all connect to the maximum number of nodes, and through a process of elimination and network mapping, figure out the direct IP address for node BiaJ8asfl9.  But this would be a very difficult undertaking.

Proposed mechanism for rollbacks

On a semi-related note, I also wonder about rollbacks, and the possibility for consensus-based rollbacks.  If a major attack on a fatal vulnerability starts in Block 21839, then a consensus of stakeholders ought to be able to agree to roll back to Block 21838 after the vulnerability has been fixed.  I propose that a consensus could be created without a central authority having anything to do with it.  If such an event were to happen, surely a large proportion of the network would be aware of it.  They would independently create rollback requests to Block 21838.  After some fixed proportion of stakeholders (25%? 50%?) have created these requests (which are put into the blockchain) then the rollback requests start showing up in people's wallets/GUI/whatchamacallits: "Do you support rolling back to Block 21838?" with a Yes or No vote (voting "Yes" adds a new rollback request for this stakeholder).  This way, consensus can be created, but it requires a large number of stakeholders independently creating the initial requests, without a central authority having to initiate or approve of anything.  Each stakeholder can only have one rollback request active at a time; they can be withdrawn at any point, at which point a "cancel" appears in the blockchain.  Once a supermajority is reached (75%? 90%?  90% of all stake active within the past week?) then the rollback occurs immediately and irrevocably.  The blockchain is simply truncated at the chosen block.

Quote from: toast on February 23, 2014, 04:32:55 pm

I don't like the lightning. A critical feature of the original picture was that the allocation proportions were shown (might not be clear because it was a shitty picture). The lightning should be replaced with something that shows value transfer correctly, like have input/output arrow width be the right proportion or something. Also AGS/PTS bars shapes should represent their growth over time but that is less important.

Hmm, I get what you're saying, but I think the value of having a lightning bolt (or some other non-arrow symbol) is to show that it doesn't represent a diminishing of the originally held asset.  You just said "value transfer", but that's not really what it is.  It's the creation of new value, and the assignment of that value based on the existing state of something else.  The use of arrows would make it look like something is flowing OUT of PTS and AGS, but that's not what's happening.  AGS and PTS continue on, undiminished.  (Which, AFAIK, is one of the main points of this chart; to show people that their PTS and AGS will not disappear once BTSXT is launched.)

In any case, I worked on it for a while, I did not feel that I could make the arrows convey the information properly.  This is partially due to my limitations as a designer.  I think I know what you mean (you see charts in magazines and such that show money flows like this: http://aleklett.files.wordpress.com/2012/11/figure-2-8-the-global-energy-system-2010.jpg ) but sometimes even fancier.  I don't have the skills to do that and make it look good, and I believe there's probably some software better suited to that kind of chart than what I'm using here.

I think that the "50% PTS, 50% AGS" text clarifies the situation sufficiently (it's even pan-lingual); and even if I managed to get the arrows to all be sized proportionately, I think that it would still need to be explained somehow, since people see arrows and lines on a chart and don't necessarily assign meaning to their widths.  Plus, now that I've played around with it some, I really think that replacing the bolts with arrows will lead to mis-interpretation.

Any reply to this?  Any other feedback?  I don't really know how to do this bounty stuff.  After reading the "Bounty Rules - Read This First" it seems that this was somewhat of an ad hoc bounty.  Not particularly well defined.  It seemed to me that the priority was speed, not perfection.  And I will note that bytemaster has already posted one of these images in another thread.

https://bitsharestalk.org/index.php?topic=3031.msg39366#msg39366

So... what's the status?  I finished the "cleaning up" portions I mentioned earlier, and the final image is posted below.  If these images meet the requirements of the bounty, I would like to get the PTS ASAP.  If these images do not meet the full requirements of the bounty, I will let someone else take over and pay me proportionally from their proceeds based on the portion of my work used.  If minor changes need to be made (text or simple layout changes) then I will make them.  However, any wholesale changes will need to be made by somebody else.  I do not feel that I could accurately represent the snapshot process by using arrows, but maybe somebody else could.