Topic: [ANNOUNCE] New alternate cryptocurrency - Geist Geld - page 16. (Read 74212 times)

I might be wrong, but I think 2112 was trying to point out the inevitable situation of a transaction transmitted over to a network, and getting lost or terribly delayed (even with the very fast Geist blocks) because there is a high enough probability that it never manages to be included in a block which is not orphaned later. This probability will be amplified as more nodes and miners join the network. It might still be OK now with less than 100 nodes active (assumption, again I might be wrong about this number).

This issue can be caused by BGP route flaps, TCP timeouts, torrent software overloading your line, bad cabling, local Ethernet switch flap or any other issue that can impair a user's connection to the network (the Geist network that is) for 10-30 seconds. These events would be a non-issue with a slower chain and definitely a non-issue with most Internet services (except Real time video/audio conferencing which cannot afford more than 1sec delay).

The number of things that can go wrong, most of them beyond the users' powers is also why few would be willing to go to the trouble to solve these issues (even if they could, as in the example of LAN issues). They would probably first give up on trying to use Geist as a transaction medium.

As far as I have read about Geist, it brings many innovative features, but in my view the fast blocks collide (pun intended) with the innovations.

Still watching to see how this goes.

As far as I understand, the splits are managed (and the "boss" chain is selected) based upon how much work went into a chain, with the most "laborious" chain "winning" and overtaking the other.


Well, the issue under discussion was somewhat different, but I find your post fascinating.

However, first and foremost my initial assumption was "hey, wouldn't it be nice to make a chain with really, really fast blocks and see if it dies screaming" (which it so far did not, and is taking it like a trooper so far  ). Now that this is out of the way, I find the issue of low-level protocol effects on Geist fascinating (though somewhat saddening because it's quite above my ability to investigate without significant outside help)

I am, however, somewhat perplexed by the idea that BGP flaps can be smooth and regular enough to repeatedly oscilate poor   Geist between two versions of the chain...

As far as I understand, BGP flap is basically a route dying and un-dying fairly rapidly due to something cute happening in a given ISP's network, which suggests that normally they should be fairly irregular and territorially contained... but the issue is absolutely worth looking into, since it makes Geist a fascinating subject of study irrespective of various "plainly pragmatic" considerations.

I'd give you a research grant but I can only pay an impressive sum either in Belorussian Roubles or in Geists, and I'm reasonably certain that Geist is a more viable form of "sorta-money" (not intended as a claim of monetary viability of Geist Geld )

I'm not an expert, but I used to eat lunches with some experts. Here's the main difference between Satoshi's approach and yours:

Satoshi made an assumption of type "assume a spherical cow in a vacuum", or in his case "assume that the interblock period is long enough to consider the underlying network observable." In other words he can neglect the inter-node transmission time and consider the time to be a discrete interblock periods.

You made an assumption of type "assume a fat cow on a muddy field", or in your case "assume that the interblock period is as short as a decent computer can squeeze them through a decent home-style Internet pipe." In other words you cannot neglect network observability, your inter-node transmission time is on the same order as a TCP/IP timeout and a BGP route flap. Thus the time in your security model cannot be discretized to just interblock period. You have to consider other cases, eg. your node is getting flapped between two competing versions of the block-chain that are producing blocks on the even/odd half-periods.

Now, from reading your previous posts I can tell that you posses both skill and attitude to solve this type of problems. Perhaps Geist Gold requires a "block-chain flap dampening patch" the same way as BGP protocol required "route flap dampening"?

Anyway, the true expert would answer: "Do you want me to write a research grant proposal?"

Yeah, something like that. But I always try to stress that it isn't the lag that kills the network protocols, it is the variance of the lag that's deadly. Find a way to buffer the variance and you'll win. I would bet that you could operate your little laundry on a asteroid with a predictable orbit with no problems, but trying to do this over the network with high variance will be extremely difficult.

Hm,  at this point I think additional expert opinion is worth inviting, since is seems to me that time can not directly factor into the gambler's ruin like that.
Hm, so basically the issue is that the split chains might get longer... but doesn't the BTC algo define "canonicity" in terms of which has most work, and not most "block count" ?

BTW, studying Geist's (hypothetical?) propensity for growing "longer" side-chains is an interesting prospect in itself...

P.S.:
Started a thread in technical about comparing security of a single validation in different alt chains.

The paper is considering the probility of successfully completing a single attack. Roughly:

6 bitcoin confirmations = 60 minutes
6 gg confirmations = 1.5 minutes

On the gg chain, you can perform 40 times as many attempted attacks in the same time period. So even if the odds for a single attack are the same, you get 40 times as many attempts, so clearly time does effect the security.

Yes, the the original paper does say that, and it's true. 6 GG confirms is much more secure than 5 GG confirms, which is much more secure than 4 GG confirms. But the paper doesn't say anything about comparing the security between 10 min blocks and 15 sec blocks. Given the same block times, each additional confirmations makes the probability of successful attack drop off exponentially. But if you try to compare the 2 chains, 1 BTC confirmation is as secure as 40 GG confirmations.

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of theses arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks" are still "6 valid blocks".

Um, I am no actuarian coblee, but it seems to me that the original bitcoin paper does not state that probability of attacker success is a function of time.

Instead, it says that "Given our assumption that p > q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases"

Again, I might be missing an elephant in the room of these arcane mathematications, but it appears that probability of attacker's success is claimed to drop off with the number of blocks, not the time spent making them, which would mean that "6 valid blocks in a net running at block per 15 secs" are as hard to overpower as  "6 valid blocks in a net running at 1 block per 10 minutes" (assuming hashrate distributions for attacker and good guys match in both of them, of course).


Hm, so basically, it will always lag behind the chain because full hidden server is so damn slow. Quite plausible a problem (I guess Bitcoin would always lag behind on, I dunno, GPRS then).

But as long as Geist can stand its ground on "vanilla nets", that strikes me as a fairly remote problem that might be solved by clever lean client design (whether it really can is another matter)


Hm, well, one might hypothetically try to have the laundry proper run "lean" and only have the "consumer-facing front" and associated proxy wallets to run G propper.... Hm. Not a bad idea it seems, I'll run it by a certain someone later...


Again, I might be failing to note an elephant here, but it seems quite explicitly stated in the Satoshi paper that attack success probability drops off with number of blocks, not time spent making them.

As for poor little i0, for the love of everything good, there are currently merely 29.811 Ghashes on i0coin.

If all people mining Geist right now conspired to overrun i0coin, it is not entirely unlikely that we could   do it (not intended to actually incite anyone towards harming the poor little coin)

I'm inclined to agree. The bitparking I0Coin exchange stopped accepting blocks last night when it detected a chain reorg going back 10 blocks, past the 10 confirmations required for a deposit. So even with 90 second blocks, 10 wasn't enough. That chain only has half the hash rate of GG though.

Well, Theymos and bitcointalk.org crew aren't really hiding. Your coin laundry will have to run hidden.

Yeah, I keep forgetting than when I talk about Tor I should be clear about the full privacy: both for a client and for a server.

I'm sorry I wasn't clear first time around. I edited my post too late.

The real test of your future coin laundry will involve setting up a Tor's hidden service. The connections "Tor<->clearnet" only test less than half of the Tor's privacy stack. To get a real statistics you'll have to setup your ghetto box behind a hidden service to connect "Tor<->Tor". Only then it will you test the full Tor stack: "hidden service directory resolution" + "connection from you to rendezvous-point" + "rendezvous-point delay" + "from rendezvoud-point to the hidden server".

If you regularly use Tor then please look up Hidden Wiki for the hidden bootstrap nodes for the original Bitcoin and try to resync the normal "bitcoind" through them after a weekend offline. Then you could try the same feat with your variant.

People frequently complain about 10 minute block interval of the original Bitcoin as way too slow. It is slow, but it reliably bootstraps through Tor. With your 15 second block intervals the bootstrap will be realy a feat of networking.

Lolcust, I think you are overly optimistic about this. 6 geist confirmations is definitely not enough to be secure. A common misconception about bitcoin is that the number of confirmations determines how safe your transaction is from a double spend attack. In reality it's how much time since your transaction that determines how safe it is. This is because the amount of time determines how likely an attack will succeed.

For example, if an attacker has 33% of the network hashrate, he has to be twice as lucky than the other miners in order to create more blocks than everyone else. It's much more likely to be twice as lucky for a period of 90 seconds (6 geist confirmations) than it is for a full 1 hour (6 bitcoin confirmations).

Are we talking stales as in Stale Shares, which implies a pool, or are we talking stales in the general sense of PoW submitted too late, which I think in case of "blocks" is usually called orphans ?

Hm, so, to put it in terms a guy who draws pictures for a living  has easier time with, I will get block propagation issues in the form of my freshly mined blocks   falling too much behind and ending up outside the 10 second window, thus getting rejected by network ?  

I guess that could be easily tested by having one of the multi-gigahash dudes trying to mine through TOR and mining for 10 mins, then through I2P's cancerous outproxy and mine for 10 mins, then directly and again 10 mins. We could compare the number of blocks accepted by the net and see if TOR or I2P result in notable loss.


Ah, sorry then. I sort of assumed you were referring to my post about validations when you said I'm overly optimistic (primarily because you quoted it )

Yes, downloading all them blocks through tor won't be pretty, but it's not like this isn't a problem Bitcoin will inevitably face    (so we might as well try out various solutions on Geist which will face it earlier). For one, unless you intend to mine or feel like being a Coin Historian, there is little practical need for getting the entire goddamned huge chain (there is a "lean" client for Bitcoin already and I think that there might be ways to make it even somewhat leaner)


I am, like right now.

I am from Belarus.

TOR is not nice but hey, you see my response right ? So mission accomplished *bush pic*
 

Basically, the standard deviation of time-delay over Tor (or probably any other anonymity network, eg. I2P) is too close to the deviation limits in your protocol. You will probably experience this once you gather more information to gather meaningful statistics.

It isn't really affecting the security of the protocol, you are right about this. It is affecting the useability of the client, especially its ability to startup and resynchronize after period of time online.

I'm thinking that you just got lucky (low variance) with Tor recently. Have you tried, eg. browsing this forum through Tor?

Edited to add: Oh I'm sorry I forgot to mention: the true test of Tor is connecting to a hidden service "*.onion". The ususal connection to the clearweb only tests less than half of the privacy stack. The complete variance is "from you to a rendezvous-point"+"rendezvous-point name resolution"+"from rendezvous-point to the counterparty". I keep forgetting about this.

Looks like at current block rate and diff there is betwen 40 and 60 GH/s on GG network.

At somepoint more GH/s I would think would not create faster blocks because of collisions in hash solving times that produce stales.

Any input?

It's entirely possible that I am overly optimistic, but I believe it would be most wonderful if one was to provide a somewhat  more elaborate explanation as to why so and which values would be reasonable to consider secure (a somewhat more elaborate argument is especially welcome in cases where certainty is claimed)

P.S.:
Geist isn't yet  popular enough for some tor dude to try to do a POSR against a Geist transaction even assuming such opportunity exists   so that would be a particularly poor way to determine transaction safety

P.P.S.:
As a matter of fact, the Geist miner on my ghettobox is connected through TOR, and it is from there that I have sent some geists to folks. To the best of my knowledge, not a single unit went AWOL (though as I said above, that hardly demonstrates anything except "this particular transaction worked out, lol" )

You need to run your Geist Gold proxied through Tor to understand why you are wrong. Satoshi was probably over-conservative. You are certainly over-optimistic.

I think I don't "get" the question. The daemon will, of course, display transactions starting from 0 and up

If what you are asking is "does Geist's security differ from Bitcoin's in terms of validation count required to consider a transaction set in the motherlovin' stone", then actually that is an interesting question to investigate, but I see no reason why math that holds for 10 min blocks won't hold for 15 sec blocks (yes, blocks are "easier" - but the time window in which you have to feed them to the victim is very much narrower, and due to the NTP thing and the narrowed down accept window, the ability to get coy with block time data is    limited too, so it should even out)

So far, I see no reason to consider a confirmation in Geist any different in terms of reliability from a confirmation in any network.

Thus, 1 is neat, 2 is secure, 3 is verily secure, everything above 3 even more secure to the point of paranoia at 6 and "you should probably buy something on Silk Road" at above 6

What I am more interested is how a narrowed-down time window affects the Finney attack (the famous one with just one confirm).
In an idealized setting, it probably should not affect it, because smaller attack time window is evened out by a "simpler" block, but methinks in a practical way it should be different because the border of Finney's attack time window is now much, much  closer to the moment where a "real life" merchant is likely to start delivering digital goods (IRL downloadable goods aren't delivered "instantly" as well)

Ok, that looks much better. That's very good it's sticking so close to projections.