alope
|
|
September 02, 2014, 11:13:03 AM |
|
Do you consider linux wallet? Of course, but later. I am looking forward to
|
|
|
|
vytasz7
|
|
September 02, 2014, 11:59:33 AM |
|
Any plans on making an asset on NXT AE , like NEM did ?
|
|
|
|
lovely89
|
|
September 02, 2014, 12:36:06 PM |
|
Any plans on making an asset on NXT AE , like NEM did ?
Why? He has an exchange up and running right now (aside from this afternoon).
|
Bitrated user: vanlovely.
|
|
|
NxtChg (OP)
|
|
September 02, 2014, 03:23:47 PM |
|
What was the sim price after the IPO, before the exchange started?
IPO closing price was 36 satoshis. Exchange down?
Yeah, damn webserver freezes occasionally. Back online.
|
|
|
|
NxtChg (OP)
|
|
September 07, 2014, 08:08:33 AM |
|
Jesus Christ, the ACH system is based on ASCII text files uploaded via FTP! http://engineering.zenpayroll.com/how-ach-works-a-developer-perspective-part-1/And yet "$39 trillion are moved through the ACH system annually". Unbelievable. An addendum to the ACH protocol to support same-day ACH settlement is something that is almost unanimously desired by the ACH community. The good news is that NACHA, the governing organization behind ACH, has recently announced plans to roll out a same-day ACH protocol. The challenge is coordinating the adoption of the new protocol across all participating banks. Once fully implemented, the same-day ACH system would likely cut one day from the timelines outlined here.
Talk about financial innovation...
|
|
|
|
NxtChg (OP)
|
|
September 07, 2014, 08:47:46 AM |
|
Progress reportAnother slow week – autumn came and with it some things I have to take care of. Only about half of the week was spent working. Finalized Transaction Gobbler (part of the Transaction Pipeline). Now focusing on client subscription. Also thought about the design of the voting system – it's surprisingly hard to implement efficiently and I don't want to compromise transaction speed for it. So this remains unsolved and it worries me a little, because once the solution is found, it might require changing the design of some parts of the system and it will take time. Need to think more about it.
|
|
|
|
cryptohunter
Legendary
Offline
Activity: 2100
Merit: 1167
MY RED TRUST LEFT BY SCUMBAGS - READ MY SIG
|
|
September 07, 2014, 09:04:02 AM |
|
a few people have tipped this coin to me. I'm holding although would be a nice return even now.
|
|
|
|
Eadeqa
|
|
September 08, 2014, 05:48:52 AM |
|
Is there estimate for launch? Something like, Winter 2015? Summer 2015?
|
|
|
|
pineapples
Legendary
Offline
Activity: 1204
Merit: 1000
to your stations, man the pineapples!!!
|
|
September 08, 2014, 07:06:54 AM |
|
Progress reportAnother slow week – autumn came and with it some things I have to take care of. Only about half of the week was spent working. Finalized Transaction Gobbler (part of the Transaction Pipeline). Now focusing on client subscription. Also thought about the design of the voting system – it's surprisingly hard to implement efficiently and I don't want to compromise transaction speed for it. So this remains unsolved and it worries me a little, because once the solution is found, it might require changing the design of some parts of the system and it will take time. Need to think more about it. is it not plausible to either handle multiple chains? or at least have multiple data types within the single chain. so voting could be on a more relaxed chain than transactions, or at least a more relaxed time frame. also different data types could have different arbitrary durations in the chain.
|
|
|
|
|
NxtChg (OP)
|
|
September 08, 2014, 08:34:49 AM |
|
is it not plausible to either handle multiple chains? or at least have multiple data types within the single chain. so voting could be on a more relaxed chain than transactions, or at least a more relaxed time frame.
also different data types could have different arbitrary durations in the chain.
I thought about doing some sort of voting tokens, but this has its own problems. People need to be able to vote with their stake. This means that at the time the poll closes the system has to calculate stakes for everybody who voted and this can take time if 100,000 people voted, for example. During this time balances must be frozen and transactions can't be processed. What I would like is to have some sort of additional "voting" balance, which is incremented with each voting transaction. But then people can move their stake to another account and vote again. Another approach would be to charge a fee to convert your account into a voting account, for example 10,000 SIM, and then just count votes. This way people can still vote with their stake by creating lots of dummy accounts, but this is bad for database size. Last option is to vote with real money, but this is also not a perfect solution and would be a bad choice for many polls.
|
|
|
|
jl777
Legendary
Offline
Activity: 1176
Merit: 1134
|
|
September 12, 2014, 06:05:39 AM |
|
is it not plausible to either handle multiple chains? or at least have multiple data types within the single chain. so voting could be on a more relaxed chain than transactions, or at least a more relaxed time frame.
also different data types could have different arbitrary durations in the chain.
I thought about doing some sort of voting tokens, but this has its own problems. People need to be able to vote with their stake. This means that at the time the poll closes the system has to calculate stakes for everybody who voted and this can take time if 100,000 people voted, for example. During this time balances must be frozen and transactions can't be processed. What I would like is to have some sort of additional "voting" balance, which is incremented with each voting transaction. But then people can move their stake to another account and vote again. Another approach would be to charge a fee to convert your account into a voting account, for example 10,000 SIM, and then just count votes. This way people can still vote with their stake by creating lots of dummy accounts, but this is bad for database size. Last option is to vote with real money, but this is also not a perfect solution and would be a bad choice for many polls. a bit more overhead, but could you take a snapshot of all the balances locally as of a specific voting time. Then the votes can come in whenever (up to a deadline) and each node can then lookup in their copy of the snapshot to give each vote the right weight. If somebody is moving around their balances, it wont matter as the weight of the vote is based on the snapshot made. probably would need to make doing a vote pretty expensive to prevent spam elections. James
|
|
|
|
NxtChg (OP)
|
|
September 12, 2014, 07:48:15 AM |
|
a bit more overhead, but could you take a snapshot of all the balances locally as of a specific voting time. Then the votes can come in whenever (up to a deadline) and each node can then lookup in their copy of the snapshot to give each vote the right weight.
Oh my god, could you please spend your feeble intellectual powers on your own projects? What local snapshot? Each node already has a "local snapshot", it's called the ledger. Making yet another copy only for accounts that voted won't make any difference, the system will still have to count, say, 100,000 votes. And how would this even work? Alice votes, I record her balance, she moves money to Bob, he votes, I record his balance, now what? And doing the copy of the whole ledger for each poll is even more retarded. Go away. Enjoy your delusion that you are a genius somewhere else.
|
|
|
|
Pentamon
|
|
September 12, 2014, 03:30:18 PM Last edit: September 12, 2014, 04:17:14 PM by Pentamon |
|
Will this work?
1. "Vote now!" is broadcast, including start time and stop times for vote. 2. Nodes receive the broadcast, make a snapshot of the current confirmed balance, and keeps that value until the stop time of the vote. So even if all fees are transferred prior to the actual vote is cast, the 'voting power' is still determined at the initial broadcast.
The price you pay, is that the unconfirmed balances in transit are not counted. Is this a big deal?
just a thought Pentamon
|
|
|
|
NxtChg (OP)
|
|
September 12, 2014, 03:36:21 PM |
|
Will this work?
1. "Vote now!" is broadcast, including start time and stop times for vote. 2. Nodes receive the broadcast, make a snapshot of the current confirmed balance, and keeps that value until the stop time of the vote.
The price you pay, is that the unconfirmed balances in transit are not counted. Is this a big deal?
I cannot make snapshots of the whole ledger. The system must scale, this means that it should work with 1 and 10 and even 100 million accounts. So the ledger can potentially be several gigabytes in size. Making a snapshot of it every time somebody creates a poll is infeasible.
|
|
|
|
|
NxtChg (OP)
|
|
September 12, 2014, 08:28:14 PM |
|
There are issues with freezing balances. For example, you can only vote in one poll at a time or there needs to be a complicated system to track these locks and their expiration dates. It's also inconvenient to have your money frozen. Would be nice to find a better solution.
|
|
|
|
Zahlen
Member
Offline
Activity: 98
Merit: 10
|
|
September 13, 2014, 01:36:04 PM |
|
Hey NxtChg! Glad to see you're working on crypto$ again. Damn I missed the IPO (by a mile!) Too much happening way too fast in cryptoland. I'll finally get to check out your exchange You might enjoy this cephalopod simulator (The original game is free, the sequel is commercial.) (Or you might break your mouse in frustration. It's the sort of game that polarizes gamers.)
|
|
|
|
ownerbest
|
|
September 14, 2014, 08:01:54 AM |
|
I think jl777 is megalomaniac now, I don't think supernet will succeed, maybe jl777 will make big money for himselft, you know.
|
|
|
|
NxtChg (OP)
|
|
September 14, 2014, 08:51:24 AM |
|
I think jl777 is megalomaniac now, I don't think supernet will succeed, maybe jl777 will make big money for himselft, you know.
Oh yeah, that's probably the best word to describe him right now. Thanks, I forgot such a nice word exists
|
|
|
|
|