 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Deciding on how people are happy about this the launch of Radix should be the date of blockchain RIP.
Seems really interesting if legit. As I understand technology behind Radix is tested and works with real company.
I'm waiting more details on economics and ICO.
The tech is tested and tested and tested.. we have spent years iterating the tech. It does indeed work and we plan to do a longer term test soon, showcasing reliability and ramping up the amount of TPS to show throughput on a shard. There is a real product already using the platform.. https://twitter.com/radixdlt/status/900357606220251136 called surematics. https://techcrunch.com/2017/08/22/yc-demo-day-s17-day-2/ |
|
|
|
Well, its works quite well.. we did a test back in April on a network, and one node on the network (mine) doing the video. Regular PC's, mine doing loads of other stuff while the nodes in the network spam each other. Video is below: https://www.youtube.com/watch?v=xw2uy_NAx7w One node was placed in Denmark, another in the UK. So, beta test, before recent database (and other) optimizations, test network across the internet. No cheating, no preload into ram. Just a straight up test to see the status at that time. |
|
|
|
|
There are some things that are currently underway, which postpones the Radix Whitepaper. Middle of July, two weeks, and much more details can be discussed.
|
|
|
|
I believe I have figured out what Fuserleer's design is doing based on re-reading the descriptions above.
I believe what he is attempting is to define a data structure wherein he can partition double-spends so that they can not cross-partition each other. In other words, once there is a double-spend, instead of discarding it (and unrelated transactions in the same chain), he isolates those transactions which depend on the double-spend and prevents them from cross-pollinating each other in derivative transactions.
The problem with this of course is it ruins the incentive to converge. It becomes a divergent block chain where the incentive is to double-spend and create forks (within the same system).
I'd be interested to hear Fuserleer's retort. I will PM him .
No need. Note the date. https://twitter.com/eMunie_Currency/status/563728882415992832 |
|
|
|
Right so that brings me to the crux of the issue that needs to be addressed. You are right, these informed traders were not
I largely considered the activity of buying low on the internal exchange and selling high on an external one as irrational, as the barrier to entry cost to trade on the internal exchange is minimal, I (perhaps incorrectly) assumed that no one would buy at the higher external price. (Are there even any valid reasons why they would?)
That was my reasoning as well. |
|
|
|
no!
they sell at a higher price elsewhere... and then deposit fiat into emunie to buy your cheap controlled coins.. then withdraw.
Why would people buy at a high price elsewhere when they too can buy on the main exchange at a lower price? - it will never happen. |
|
|
|
I didn't alter the sentiment of the trades though, the sentiment of every single one of those 58M trades is exactly as it was.
but by changing the trades, (making the $1000 never happen) you are changing the sentiment, which then effects future sentiment. and that is the exact problem, by not considering that sentiment will change because of your actions. you have failed to take that into account.. as ciyam said.. it wont work with live data as that involves live human emotion and change of sentiment in reaction to your model What you're talking about is the market dynamics during a pump (FOMO) and dump (fear), which is correct.However, you're wrong. The test is done so that the sentiments are tested, which gives a worst case scenario for the price stability mechanism. In a live testing, these extremes will be much less pronounced and hence the stability will be easier to keep. It does not invalidate the algorithm, it backs it up since it will likely not see such pressures in live environment. |
|
|
|
Not exactly relevant to the discussion of our economics model as there is no autonomous entity within these exchanges serving to smooth out the volatility.
Huh? You don't think that it is software that decides to stop the trading? (the software might get its orders from the government but I am pretty certain that the actual decision to stop the trading is done by software) Stopping trades for a short time does little to smooth out movements. It only prolongs them to when the exchange reopens. Our stability mech. allows continuous operation. |
|
|
|
Second thing I see here, is that many are concentrating on "confirmed tx/s", but rather banks leave transactions as pending for days until the funds finally reach their destination. The initiation of the transaction is purely just protocol aka memory pool, and the confirmation in reference to digital currencies can be see as "gotten on a block ". You use account channels from what I understand of your implementation, how do you arrive at consensus if lets say I send merchant A coins, and also send myself coins from a node across the world at the exact same timestamp. How will the consensus be reached as to which is the valid transaction? How will the distributed network recover from lets say the trans atlantic cables being out of service cutting europe from the usa for an hour even, which at 2k transactions per second would be 7.2M transactions. And let's say 3.1M happen in US that directly conflict with 3.1M in europe, how will the network reorganize and reach a consensus once again?
Thank You,
Viz.
Concensus primer here. Needs some revision, but the overall answer is there to answer your question https://bitcointalk.org/index.php?topic=1159624.0 |
|
|
|
Did you read the web page before challenging the choice of platform for dev? Update 2009 JAVA 1.6 reaches ~95% performance of C++ |
|
|
|
Great idea!!
Most crypto agnostics here who aren't priests in any particular crypto religion just want to see good coins, platforms & developers well supported, so a Crypto Olympics to help the cream float to the top would be really cool ... and FUN!!
The problem, as I already stated, is that speed is irrelevant until you can show the system functions in the wild without imploding from one of it's own flaws, being exploited to death, or showing it doesn't have deficiencies that a regular blockchain doesn't. The original poster made the thread under the guise of being a non-biased 3rd party, yet it's blatantly obvious it's an Emunie sock puppet account trying to do something like increase IPO payout. Dan isn't stupid and has a good chance of possibly creating something viable, but trying to insult people's intelligence by having obvious shills like "peachy" and this guy posting and pretending to be non-biased observers doesn't help. As one of the emunie founders, i can tell you straight up that you are wrong. Wingspan DOES have an emunie forum account. He's a beta tester along with alot more people on our own forum. You can even find info and pictures of Wingspan. A little googling around and you will find its an account that has ZERO to do with Dan. Please bury the hatchet gentlemen. However, emunie IS interested in doing some 1 to 1 testing with other crypto to prove how far its come. In the past week, we've seen performance claims being way overinflated on a "real" testnet. All it does is it hurts the cryptocommunity - it implodes from the inside. What emunie offers is nothing more than a proof that the claims of 2500 tps peak - evidenced by both screenshots and direct video capture - are all attainable on hardware that can easily be sourced for a test like this. We use regular PC hardware - no asics or server grade hardware needed. As it seems, the resistance towards this - hopefully fair - test is that it will show just how overinflated some claim are. Investors should demand these tests before they invest their money - else its just the old hype before launch, underdeliver and subsequent dump on exchanges. Everybody looses out - money and trust. |
|
|
|
I don't need to know how Bitshares works in detail to apply general computer science theory to the claims made.
...ell seeing as Larimer himself said the solution is to "...keep everything in RAM..." how much RAM to do think is required to keep up with a sustained 100,000 tps if it is indeed true?
Just for the record, cross post from https://bitcointalk.org/index.php?topic=1196533.msg12575441#msg12575441I want to address the MAJOR misconception and that is that we keep all transactions in RAM and that we need access to the full transaction history to process new transactions.
The default wallet has all transactions expiring just 15 seconds after they are signed which means that the network only has to consider 1,500,000 * 20 byte (trx id) => 3 MB of memory to protect against replay attacks of the same transaction.
The vast majority of all transactions simply modify EXISTING data structures (balances, orders, etc). The only type of transaction that increases memory use permanently are account creation, asset creation, witness/worker/committee member creation. These particular operations COST much more than operations that modify existing data. Their cost is derived from the need to keep them in memory for ever.
So the system needs the ability to STREAM 11 MB per second of data to disk and over the network (assuming all transactions were 120 bytes).
If there were 6 billion accounts and the average account had 1KB of data associated with it then the system would require 6000 GB or 6 TB of RAM... considering you can already buy motherboards supporting 2TB of ram and probably more if you look in the right places (http://www.eteknix.com/intels-new-serverboard-supports-dual-cpu-2tb-ram/) I don't think it is unreasonable to require 1 TB per BILLION accounts. Ok that clears that up, maybe he should be a bit more clear in future about what exactly "...keep everything in RAM..." means. It still leaves a lot of questions unanswered regarding that claim though, specifically the IO related ones. Streaming 11MB from disc doesn't sound like its too hard, but it depends on a number of factors. Reading one large consecutive 11MB chunk per second is of course childs play, but if you are reading 11MB in many small reads (or worse still if its a mechanical platter drive and is fragmented) then that simple task becomes not so simple. Also, network IO seems to have some potential issues. 11MB/s down stream isn't too much of a problem, a 100Mbit downstream line will just about suffice, but what about upstream? I'm assuming (so correct me if Im wrong), that these machines will have numerous connections to other machines, and will have to relay that information to other nodes. Even if each node only has a few connections (10-20), but has to relay a large portion of those 100,000 tps to each of them, upstream bandwidth requirements for that node quickly approach multiple gigabits in the worst case. Further more, lets assume that Bitshares is a huge success, is processing just 10,000 tps sustained and that none of these issues exist other than storage. As Bitshares relies on vertical scaling, and we've already determined that 100,000 tps = ~1TB of data a day, 10,000 tps = 100 GB daily. Operators of these machines are going to be spending a lot of dollar on fast drive space and have to employ sophisticated storage solutions in order to keep pace. This becomes quite insane at the 100,000 tps level (365TB per year), perhaps Bitshares has some chain pruning or mechanisms to keep this down? (I hope so!) Finally back to RAM requirements, what are the measures or mechanisms in place to prevent someone from creating 1Billion or more empty accounts, and causing RAM requirements to shot upwards as this information is kept in RAM? A few machines could easily do this over the course of a couple of weeks if there are no other costs associated with it, I assume there is some filtering to only keep accounts with activity in RAM as otherwise this will be a major issue. Eitherway, this is just another example how vertically scaled systems are not viable, should Bitshares grow to the level where it is processing 100,000s of transactions per second and has even a few 100M accounts, you need a machine with 100s of GB of RAM, 100s of TB of storage, and internet connections in the multiple GB speeds.....not really accessible to the man on the street. Perhaps the cost of participating at that level just isn't an issue, as Bitshares has always had a semi-centralized element to it anyway, and most supporters of it don't seem to mind it. For me though, relying on ever increasing hardware performance and sacrificing core principles which brought us all here in the first place is a cop out. 2046483ms th_a application.cpp:516 get_item ] Couldn't find block 00008e220adc1561e0ceb4964000000000000000 -- corresponding ID in our chain is 00008e220adc1561e0ceb496e2fe61effc44196e
2046486ms th_a application.cpp:432 handle_transaction ] Got transaction from network
./run.sh: line 1: 8080 Segmentation fault ./witness_node --genesis-json "oct-02-testnet-genesis.json" -d oct02 -w \""1.6.0"\" -w \""1.6.1"\" -w \""1.6.2"\" -w \""1.6.3"\" -w \""1.6.4"\" -w \""1.6.5"\" -w \""1.6.6"\" -w \""1.6.7"\" -w \""1.6.8"\" -w \""1.6.9"\" -w \""1.6.10"\" -w \""1.6.11"\" --replay-blockchain This is what the init node said before it died during the flood. We are looking into what could have caused it. As far as release plans go, we will protect the network from excessive flooding by rate limiting transaction throughput in the network code. We recently made a change that allowed a peer to fetch more than one transaction at a time and that change is what allowed us to hit 1000+ TPS. That change had the side effect of making the network vulnerable to flooding. For the BTS2 network we will revert to only fetching 1 transaction at a time which will limit throughput of the network to under 100 TPS. This will only be a limit in the P2P code which can be upgraded at any time without requiring a hard fork. If the network is generating anywhere near 100 TPS per second then the network will be earning more than $1M per day in fees and our market cap would be closer to Bitcoins market cap. In other words, this should have 0 impact on customer experience over the next several months. By the time we start gaining traction like that we will have worked through the kinks of getting a higher throughput network layer. So as can be evidenced here, while Bitshares did reach 1000 tps (peak!) during their internal tests, it caused stability issues that put the test to a halt. In order to resolve it, they have pegged the throughput to 100 tps max due to network IO issues. Link to post https://bitsharestalk.org/index.php/topic,18717.msg241280.html#msg241280 |
|
|
|
We have quite a few ideas to take crypto from the state it is now to main street. Exact details are not given since they will be stolen by others - we've experienced that before. There will be plenty incentives to go for the emunie route instead of regular VISA cards. We will "spill the beans" when the time is right.  |
|
|
|
Is it possible to invest in this project?
Not yet, its not launched and there is no public fundraiser scheduled atm. This is a cool project, and cryptos need to find a way to be as fast as possible for the masses to want to adopt, due to their fast paced life styles, IMO... so when do you think the official release of this coin will be? Any ideas? There are no "deadlines" - we will release when its done. No Deadlines allows us to experiment and find new solutions even though we thought we had found it - and test those out.. We probably have disapointed more people stating deadlines than with no deadlines because people won't get all exiting we are gonna launch soon with tech we have much improved only to get their hopes down. If you're really interested in the project, you can go to our forum and ask to be a beta tester and help test it out after the founder tests (who tests the "alpha" versions). There will soon be a new beta to be tested. |
|
|
|
I thought this developer had already been found to be a scammer, people should research his past threads on this forum. It's not pretty.
If they did, they would actually find he's NOT a scammer. Please, if you don't mind, post some actual proof (if you have any) and lets take it from that once and for all. |
|
|
|
if Daniel had invested into NXT like he almost did.
He would had said "SFYL" (sorry for your loss) and would had left his baby Peachy & "investors" behind holding an empty bag. Daniel would had left eMunie to be a NXT developer. This really proves that Fuserleer was a greedy chump then and still is today.
This is just wrong  I think nxt is sad Dan did not invest his time in their project.. not the other way around. Right now, nxt is on a 12th place on coinmarketcap - behind DogeCoin. 'nuff said. |
|
|
|
Count me in as another proud investor without issue for over 2 years and I'm willing to wait as long as it takes.
With regard to the development timeline, just remember we've had 6000 years of human-controlled/manipulated currency and all of it's inherent problems. I think taking a few years to build an autonomously decentralized version is more than justified.
As for the baseless criminal accusations. Oh puhLEEZ. I've flown from Texas to the UK to meet with him personally and can 100% vouch for his credibility and acumen.
Like Peachy, i've also trusted Dan with my personal funds for a long period of time and would not hesitate to contribute more. Dan could have launched a long time ago at the peak of the bitcoin hype train back in December 2013 and made much more money than he have ever had in emunie investments. He spends countless days and nights coding - to me, that seems like too much of a hazzle if you want to scam everyone. It would be much easier to finish a gui, crack on a Wordpress template and spend the weekend at the Hilton spending other peoples money. |
|
|
|
The p2p credit card is genius... but how will you get merchants to adopt a currency with massive volatility? They need fiat stability?
You make supply elastic, so you can lever both quantity and price if demand increases (or reduces). |
|
|
|
Hehe, why dose everything good have to take so long? I will wait patiently ....like I have for the last two years But I will try to catch the next test. Its been like one year almost that I participated in one I think. In that case. you can surely look forward to alot of improvements. Back then, we were still using the - comparatively - slow block tree. We usually do alot of founder testing and its been a while since the regular beta testers saw a beta. That should change soon We are working hard to get this on the market. Even pulling some tests to late in the night (for me atleast). However, eMunie is a monumental project so as you already know, it takes time. Thanks for your patience! |
|
|
|
|
