Search content
Sort by
Showing 20 of 234 results by Zahlen
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.)
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.)
Re: Transparent mining 2, or What part of Legacy should be left behind
Thanks. 
Some consequences:
None of this requires thinking of Nxt as a currency (or in fact, Nxt at all. I've tried to avoid terms like "blockchain" which I suspect have a lot of pre-established "freight", I prefer to talk about the more general concepts like "version of history"). Nxt, or rather effective stake, is just how often you get to update a version of history, i.e. how much say you have in the history. Right now, I think of Nxt as a way to come to consensus on a version of history. Not just a history of $ transaction, but potentially for any events that can be recorded digitally.
If Nxt is not a currency, then it doesn't make sense to talk about profiting from requesting events to be added to versions of histories (transactions). It does make sense to make such requests free. But in practice, in Nxt, current technology is still limited, we need to limit (ab)use with a cost to transactions. If we are to have costs, it makes sense for such costs to depend on the type of tx being sent (as in fixed fees), since different txs have different costs in terms of space and processing requirements of the entire network. Rather than depend on the amount of Nxt you're sending (as in proportional fees), since the more effective stake and influence you have, the more you should be able to do.
(I think jl has already talked a lot about these last two paragraphs, just in different terms.)
Some consequences:
None of this requires thinking of Nxt as a currency (or in fact, Nxt at all. I've tried to avoid terms like "blockchain" which I suspect have a lot of pre-established "freight", I prefer to talk about the more general concepts like "version of history"). Nxt, or rather effective stake, is just how often you get to update a version of history, i.e. how much say you have in the history. Right now, I think of Nxt as a way to come to consensus on a version of history. Not just a history of $ transaction, but potentially for any events that can be recorded digitally.
If Nxt is not a currency, then it doesn't make sense to talk about profiting from requesting events to be added to versions of histories (transactions). It does make sense to make such requests free. But in practice, in Nxt, current technology is still limited, we need to limit (ab)use with a cost to transactions. If we are to have costs, it makes sense for such costs to depend on the type of tx being sent (as in fixed fees), since different txs have different costs in terms of space and processing requirements of the entire network. Rather than depend on the amount of Nxt you're sending (as in proportional fees), since the more effective stake and influence you have, the more you should be able to do.
(I think jl has already talked a lot about these last two paragraphs, just in different terms.)
Re: Transparent mining 2, or What part of Legacy should be left behind
Dealing with many versions of history:
In the approach described in the above posts, you can never be sure which version of history is the right one, in fact, it's not meaningful to talk about a "right" version of history, only different versions of history that you have different confidence about. It may turn out that one version of history preferred by H right now may not extend to the version preferred by H in the next block. For the most part, that's ok, because most versions will be identical except for small differences due to transactions not reaching the deciders/dropped. So you just request to add your events to your most preferred versions of history as determined by H, and stick to just the most preferred resulting versions of history.
To avoid dealing with an exponentially growing tree of histories and save computing resources, you can discard the least preferred versions of history. e.g. if H is the lowest sum of HIT/EFFECTIVE_STAKEs, you can know the probability distribution of the lowest HIT/EFFECTIVE_STAKE during each block by sampling previous blocks. If you know that the difference between the lowest HIT/EFFECTIVE_STAKE and say the 10th lowest HIT/EFFECTIVE_STAKE has never been greater than e and will likely almost never be greater than e, then you can just keep the history with the lowest sum SUM of HIT/EFFECTIVE_STAKEs in memory, along with just those histories whose sum are less than SUM + e and discard the rest. In the unlikely event that the versions of history that the rest of the network prefers are built on an old version that you discarded, then you end up on a fork, and you'll have to deal with it manually by redownloading the histories from somewhere you trust.
This is when all the actors are honest. When there are dishonest actors, then large differences from deliberate actions by them can occur. So the problem is how to discover who they are, and consequently blacklist them and reject their versions of history. This could be done outside the network of actors and events, through e.g. RL investigation. It could also be done within the network. e.g. if the versions of history broadcast by a certain actor frequently don't include the events involving you that are sent to them while other versions of history do, that suggests that actor is not being honest with you. You may want to prefer other versions of history that did include your events (or if you think it's not a big deal just try to include that event again later based on the same history, when it is a different decider's turn), and you may want to increase their blacklist weight, and announce the discrepancy to other actors so they can likewise increase their blacklist weights.
In the approach described in the above posts, you can never be sure which version of history is the right one, in fact, it's not meaningful to talk about a "right" version of history, only different versions of history that you have different confidence about. It may turn out that one version of history preferred by H right now may not extend to the version preferred by H in the next block. For the most part, that's ok, because most versions will be identical except for small differences due to transactions not reaching the deciders/dropped. So you just request to add your events to your most preferred versions of history as determined by H, and stick to just the most preferred resulting versions of history.
To avoid dealing with an exponentially growing tree of histories and save computing resources, you can discard the least preferred versions of history. e.g. if H is the lowest sum of HIT/EFFECTIVE_STAKEs, you can know the probability distribution of the lowest HIT/EFFECTIVE_STAKE during each block by sampling previous blocks. If you know that the difference between the lowest HIT/EFFECTIVE_STAKE and say the 10th lowest HIT/EFFECTIVE_STAKE has never been greater than e and will likely almost never be greater than e, then you can just keep the history with the lowest sum SUM of HIT/EFFECTIVE_STAKEs in memory, along with just those histories whose sum are less than SUM + e and discard the rest. In the unlikely event that the versions of history that the rest of the network prefers are built on an old version that you discarded, then you end up on a fork, and you'll have to deal with it manually by redownloading the histories from somewhere you trust.
This is when all the actors are honest. When there are dishonest actors, then large differences from deliberate actions by them can occur. So the problem is how to discover who they are, and consequently blacklist them and reject their versions of history. This could be done outside the network of actors and events, through e.g. RL investigation. It could also be done within the network. e.g. if the versions of history broadcast by a certain actor frequently don't include the events involving you that are sent to them while other versions of history do, that suggests that actor is not being honest with you. You may want to prefer other versions of history that did include your events (or if you think it's not a big deal just try to include that event again later based on the same history, when it is a different decider's turn), and you may want to increase their blacklist weight, and announce the discrepancy to other actors so they can likewise increase their blacklist weights.
Re: Transparent mining 2, or What part of Legacy should be left behind
The history preference function H:
(This part I don't understand well. Please help me improve my understanding.)
H is supposed to select a preferred history (or rather like D, a sequence of histories of decreasing preference) to build on from a set S of known possible histories, so write H(S) to represent this.
I think you want H to be consistent with D: Suppose you're at a version of history h right now, and D chooses as decider account a_1 as the first candidate, a_2 as the second candidate, and so on. If the updated versions of history proposed by each a_n is h_n respectively, H should prefer h_1 over h_2, h_2 over h_3 and so on. One way to achieve this is for H to prefer the version of history with the smallest sum of all previous HIT/EFFECTIVE_STAKEs of previous deciders in that version of history, since if you have two versions of history differing only in the last block, the HIT/EFFECTIVE_STAKEs are all the same except for the last decider, so the version with the smallest sum is also the one whose last decider has the smallest HIT/EFFECTIVE_STAKE.
But folks in the main thread were talking about largest sum of 1/EFFECTIVE_STAKEs (of just the deciders?), which isn't consistent in the way I described here, so I don't get this part. Am I missing something?
H should likewise be consistent with any blacklisting used, I'm not sure what a good modification would be.
(This part I don't understand well. Please help me improve my understanding.)
H is supposed to select a preferred history (or rather like D, a sequence of histories of decreasing preference) to build on from a set S of known possible histories, so write H(S) to represent this.
I think you want H to be consistent with D: Suppose you're at a version of history h right now, and D chooses as decider account a_1 as the first candidate, a_2 as the second candidate, and so on. If the updated versions of history proposed by each a_n is h_n respectively, H should prefer h_1 over h_2, h_2 over h_3 and so on. One way to achieve this is for H to prefer the version of history with the smallest sum of all previous HIT/EFFECTIVE_STAKEs of previous deciders in that version of history, since if you have two versions of history differing only in the last block, the HIT/EFFECTIVE_STAKEs are all the same except for the last decider, so the version with the smallest sum is also the one whose last decider has the smallest HIT/EFFECTIVE_STAKE.
But folks in the main thread were talking about largest sum of 1/EFFECTIVE_STAKEs (of just the deciders?), which isn't consistent in the way I described here, so I don't get this part. Am I missing something?
H should likewise be consistent with any blacklisting used, I'm not sure what a good modification would be.
Re: Transparent mining 2, or What part of Legacy should be left behind
The decider function D:
We want each actor to be selected as decider with frequency proportional to their effective stake. But each actor may not be reachable (online) all the time. They may also not be honest or accurate. So we want D to select not just one decider, but a sequence of candidate deciders of the next versions of history, so that actors can have a choice between alternative versions of history via the preference function. We also want D to be based on the version of history h you wish to extend with your current events, we write D(h) to reflect this.
One way for D(h) to satisfy this is via:
1) For each account with a positive effective stake, roll a deterministic die based on the history h you wish to extend. Call the result HIT
2) Order all such accounts in increasing HIT/EFFECTIVE_STAKE.
3) The first account that is reachable (online) is the first candidate, the next reachable account is the second, etc.
This D does indeed choose each actor with frequency proportional to their effective stake, as the number of accounts with an effective stake grows to infinity. (subject to simple niceness conditions; ask me if you're interested in the proof).
When you want to extend a version of history with your current events, you send a request to the first few candidates. Send to more to increase the chances of your events being included in some version of history.
I think the above is what's known so far about TF, from BCNext via CfB. This assumes all actors are honest and accurate, which not all will be. Below is one possible (untested) modification:
Each actor maintains a personal weighted blacklist of other actors that they believe to be dishonest, inaccurate, or otherwise do not wish to send their information to. The weights are probabilities of not choosing them as a candidate decider and so not sending your events to them when you would normally do so. So a weight of 1 would mean never send them any events. Weights are updated as new information is gained about other actors and your confidence in their honesty and accuracy changes.
We want each actor to be selected as decider with frequency proportional to their effective stake. But each actor may not be reachable (online) all the time. They may also not be honest or accurate. So we want D to select not just one decider, but a sequence of candidate deciders of the next versions of history, so that actors can have a choice between alternative versions of history via the preference function. We also want D to be based on the version of history h you wish to extend with your current events, we write D(h) to reflect this.
One way for D(h) to satisfy this is via:
1) For each account with a positive effective stake, roll a deterministic die based on the history h you wish to extend. Call the result HIT
2) Order all such accounts in increasing HIT/EFFECTIVE_STAKE.
3) The first account that is reachable (online) is the first candidate, the next reachable account is the second, etc.
This D does indeed choose each actor with frequency proportional to their effective stake, as the number of accounts with an effective stake grows to infinity. (subject to simple niceness conditions; ask me if you're interested in the proof).
When you want to extend a version of history with your current events, you send a request to the first few candidates. Send to more to increase the chances of your events being included in some version of history.
I think the above is what's known so far about TF, from BCNext via CfB. This assumes all actors are honest and accurate, which not all will be. Below is one possible (untested) modification:
Each actor maintains a personal weighted blacklist of other actors that they believe to be dishonest, inaccurate, or otherwise do not wish to send their information to. The weights are probabilities of not choosing them as a candidate decider and so not sending your events to them when you would normally do so. So a weight of 1 would mean never send them any events. Weights are updated as new information is gained about other actors and your confidence in their honesty and accuracy changes.
Re: Transparent mining 2, or What part of Legacy should be left behind
Wanted to clarify my understanding of Nxt's TF approach to proof of stake. Going to try to write it out here, hope folks can comment/correct/ask about stuff and help me improve my understanding. I'm unable to keep up with the main thread, sorry if all this has been brought up before. Thanks!
Regard time where events (transactions) are occuring as discrete (say in 60 sec blocks). The consensus problem: how do we get a group of actors (Nxters, nodes) to come to an agreement on a common, consistent version of history (blockchain branch), given that no one can see the entire network at any point in time, each actor only knows about his own actions, and maybe the actions of actors near him. And this becomes more difficult as not everyone can be assumed to be always honest or accurate.
The simplest way to come to consensus is to accept what one actor decides as the version of history. This is the starting point of Nxt. So the general consensus problem now reduces to the problem of agreeing on which actor should be the one to decide (forge the block). Let D be the function that determines who is the one to decide.
Again, the decider does not see the entire network. In order to get information, other actors must send information about their events to the decider. It's inefficient to send information about all of your past events, so to simplify, each actor sends only events that they originate during the current block of time and state which version of history these events are based on. The decider then updates the version of history with the information received. The other actors may not see the decider as well, so after updating the decider broadcasts the updated version of history to other actors, who continue to help broadcast it.
We cannot have the same actor always decide, since they may not always be honest or accurate. So we need to regularly change the decider, have different actors decide for different blocks of time. We don't necessarily want all actors to decide the same fraction of the time, i.e. to not all have the same say. Call the proportion of the time where an actor gets to decide their effective stake. So effective stake is a measure, and basis of an actor's influence in the version of history. This is why we say Nxt is proof of stake.
Even if everyone agrees at a point in time to one actor's version of history, that version may not be honest or accurate. So we need to be able to switch versions of history, to prefer one history over another. Call this preference function H.
Let's investigate the properties that D and H should have, and then hopefully be able to define them.
(There is a third function I that determines which events the decider wishes to include into the updated version of history. This is not so important, I think it can be left up to each actor, so I won't go into it here.)
Regard time where events (transactions) are occuring as discrete (say in 60 sec blocks). The consensus problem: how do we get a group of actors (Nxters, nodes) to come to an agreement on a common, consistent version of history (blockchain branch), given that no one can see the entire network at any point in time, each actor only knows about his own actions, and maybe the actions of actors near him. And this becomes more difficult as not everyone can be assumed to be always honest or accurate.
The simplest way to come to consensus is to accept what one actor decides as the version of history. This is the starting point of Nxt. So the general consensus problem now reduces to the problem of agreeing on which actor should be the one to decide (forge the block). Let D be the function that determines who is the one to decide.
Again, the decider does not see the entire network. In order to get information, other actors must send information about their events to the decider. It's inefficient to send information about all of your past events, so to simplify, each actor sends only events that they originate during the current block of time and state which version of history these events are based on. The decider then updates the version of history with the information received. The other actors may not see the decider as well, so after updating the decider broadcasts the updated version of history to other actors, who continue to help broadcast it.
We cannot have the same actor always decide, since they may not always be honest or accurate. So we need to regularly change the decider, have different actors decide for different blocks of time. We don't necessarily want all actors to decide the same fraction of the time, i.e. to not all have the same say. Call the proportion of the time where an actor gets to decide their effective stake. So effective stake is a measure, and basis of an actor's influence in the version of history. This is why we say Nxt is proof of stake.
Even if everyone agrees at a point in time to one actor's version of history, that version may not be honest or accurate. So we need to be able to switch versions of history, to prefer one history over another. Call this preference function H.
Let's investigate the properties that D and H should have, and then hopefully be able to define them.
(There is a third function I that determines which events the decider wishes to include into the updated version of history. This is not so important, I think it can be left up to each actor, so I won't go into it here.)
Re: Nxt :: Automated Transactions (AT) - progress and discussion
I've also specified that the start of the data area (for constants) could be provided with the AT creation tx.
Oh right! I missed that.
Re: Nxt :: Automated Transactions (AT) - progress and discussion
Another update - I've removed four op codes (ADD_VAL, SUB_VAL, MUL_VAL and DIV_VAL) so that the only op code that requires a 64 bit value is SET_VAL.
With this change, would it still be wise to initialize data pages as 0? Cause then you may have to SET a lot of VALs through the code pages first.
EDIT: I was just talking about which accounts an AT could send transactions from, definitely makes sense to restrict that. Hadn't thought about the "to" part either.
Re: Nxt :: Automated Transactions (AT) - progress and discussion
Regarding Turing completeness, I have the math background to answer:
Saying that a programming language (whether AT, or Ethereum, or C++, or anything else) is "Turing complete" means that it can perform all the calculations that a Turing machine can perform. A Turing machine is a technical math/CS concept, but the key thing to take away for this discussion is that Turing completeness only says something about the calculations that can be performed. It doesn't say anything about actions.
Turing completeness is a good thing! It means ATs can read data sent to it and add, subtract, multiply, divide, compare this data, and perform all other computations that you'd normally expect a computer to be able to do.
Bad AT behaviour may indeed be possible, from actions like e.g. spamming AMs. But Turing completeness doesn't say anything about actions like sending nxt, or composing and sending an AM. These would be additional features of ATs. It's up to Ian and his team to decide what actions ATs should be allowed to/not allowed to do, to guard against bad behaviour.
As I understand, Ian's writing a virtual machine (VM) for ATs. That means a place set aside for ATs to perform their calculations, and that means ATs won't be allowed to interfere with the rest of your computer. I think ATs will also only be allowed to send transactions from the account that they're "assigned" to, so that's another good restriction.
Saying that a programming language (whether AT, or Ethereum, or C++, or anything else) is "Turing complete" means that it can perform all the calculations that a Turing machine can perform. A Turing machine is a technical math/CS concept, but the key thing to take away for this discussion is that Turing completeness only says something about the calculations that can be performed. It doesn't say anything about actions.
Turing completeness is a good thing! It means ATs can read data sent to it and add, subtract, multiply, divide, compare this data, and perform all other computations that you'd normally expect a computer to be able to do.
Bad AT behaviour may indeed be possible, from actions like e.g. spamming AMs. But Turing completeness doesn't say anything about actions like sending nxt, or composing and sending an AM. These would be additional features of ATs. It's up to Ian and his team to decide what actions ATs should be allowed to/not allowed to do, to guard against bad behaviour.
As I understand, Ian's writing a virtual machine (VM) for ATs. That means a place set aside for ATs to perform their calculations, and that means ATs won't be allowed to interfere with the rest of your computer. I think ATs will also only be allowed to send transactions from the account that they're "assigned" to, so that's another good restriction.
(Not a candidacy statement, just wanted to comment on the campaigning process.)
1) A candidate does not need to be good at writing English. Some candidates may not have English as their mother tongue. If you're voting, don't confuse lots of writing for ability to judge the worth of a project. Remember that ultimately the committee's job is to decide which projects get funded.
2) Consequently, writing about everything you think you can bring to the table may not help your case. Being succinct is being clear. Too many words may just be information overload for voters. (Maybe we could have separate threads for the different committees?) If you want to sell your case, you should make your case easy to understand. IMO candidates should be able to freely edit their posts.
3) In another thread, I suggested that candidates could say something about what working experience they've had to help their case. But saying too much about your profession(s) can give away your identity. If you want to stay anonymous, you could just mention what you think are your most relevant fields of expertise.
(Odd numbers are cool, so this sentence isn't a point.)
1) A candidate does not need to be good at writing English. Some candidates may not have English as their mother tongue. If you're voting, don't confuse lots of writing for ability to judge the worth of a project. Remember that ultimately the committee's job is to decide which projects get funded.
2) Consequently, writing about everything you think you can bring to the table may not help your case. Being succinct is being clear. Too many words may just be information overload for voters. (Maybe we could have separate threads for the different committees?) If you want to sell your case, you should make your case easy to understand. IMO candidates should be able to freely edit their posts.
3) In another thread, I suggested that candidates could say something about what working experience they've had to help their case. But saying too much about your profession(s) can give away your identity. If you want to stay anonymous, you could just mention what you think are your most relevant fields of expertise.
(Odd numbers are cool, so this sentence isn't a point.)
I've removed my name from the list of Tech Committee nominees. (But thank you mysterious stranger for nominating me ) I might be busy come April and won't be able to keep up with the going-ons. Don't want to be made a committee member, only to not show up for any discussions and voting afterwards.
Maybe I'll try for a committee seat the next time round
EDIT:
This is the man who will change the future. Mario123 2014!
) I might be busy come April and won't be able to keep up with the going-ons. Don't want to be made a committee member, only to not show up for any discussions and voting afterwards.Maybe I'll try for a committee seat the next time round
EDIT:
4. my wife can pronounce and spell NXT and knows the importance of having no "coin" in the name
5. I like odd numbers, that's why there is a fifth point
5. I like odd numbers, that's why there is a fifth point
This is the man who will change the future. Mario123 2014!
Re: Nxt :: Automated Transactions (AT) - progress and discussion
Code:
SUB_LEQ 0x89 addr1,addr2,addr3 @addr1 -= $addr2, if $addr1 <= 0 then pc = $addr3 (for James)
Please tell me I've got it right this time!
I'm sorry, I don't think I can.
Spec needs to be pc = addr3, without the $.Maybe it's my use of the variable name "addr3" that's the confusion; addr3 is supposed to be a value representing an address, not the value pointed to by an address. It should behave like JUM_ADR. (I do math mainly, not coding, so I'm not used to naming conventions.) So maybe
Code:
SUB_LEQ 0x89 addr1,addr2,addr_value @addr1 -= $addr2, if $addr1 <= 0 then pc = addr_value (for James)
would remove any confusion?
Re: Nxt :: Automated Transactions (AT) - progress and discussion
It might also make sense to have an AT "priority" setting (a bit like task priority) so that lower priority ATs might only be run at most every X blocks.
Yeah some form of triage makes sense, since computational resources may be limited. AT coders should be coding ATs in such a way that they don't have to be running every block to successfully complete execution anyways, since things like running out of funds could happen.
Code:
if( state.jumps.count( state.pc + addr3 ) )
state.pc += addr3;
state.pc += addr3;
Actually, that still isn't the subleq branching. SUBLEQ a, b, c means that after you perform a = a - b, if that is <= 0, you goto c, not the address pointed to by c, or advance the code point by c. So you'll want pc = addr3 instead.
(I don't know whether to feel proud or guilty about optimizing subleq!)
Re: Nxt :: Automated Transactions (AT) - progress and discussion
Code:
:loop
get tx at after @timestamp and store in @txid
if @txid is zero finish
get timestamp for @txid and store in @tx_time
get tx type for @txid and store in @tx_info
if @tx_info != @am_type_subtype goto skip
get tx at after @timestamp and store in @txid
if @txid is zero finish
get timestamp for @txid and store in @tx_time
get tx type for @txid and store in @tx_info
if @tx_info != @am_type_subtype goto skip
But this way requires the script to be constantly polling for "triggers" (here am_type_subtype), which will require extra cycles (and hence cost) right? (Or would the extra cost be negligible?)
I was thinking that instead of pausing/sleeping for a predetermined period, during which the script can't execute and can't poll, you could have some mechanism that allow triggers to wake up the script (or at least run a function that checks whether the trigger is something valid for the script to wake up for).
Re: Nxt :: Automated Transactions (AT) - progress and discussion
Just read the spec document, was a pleasure to read. Wish more devs (and mathematicians!) would write as clearly and explain motivations like you do.
Some thoughts about the op codes:
1) Would it be useful to have a pause code and a resume code? Maybe for event handling, e.g. onAMReceived() { resume; } ? (Is running out funds the only way to pause a running script?)
2) A note for James: subleq isn't exactly 0x89 SUB_LEQ, it's actually
@addr1 -= $addr2, if $addr1 <= 0 then pc = addr3, rather than pc += $addr3 . James, you'll need to compose it with additional instructions to have it match up with the subleq used in the example C++ libraries.
(This must be Ian's plan to slow subleq even further
)
Some thoughts about the op codes:
1) Would it be useful to have a pause code and a resume code? Maybe for event handling, e.g. onAMReceived() { resume; } ? (Is running out funds the only way to pause a running script?)
2) A note for James: subleq isn't exactly 0x89 SUB_LEQ, it's actually
@addr1 -= $addr2, if $addr1 <= 0 then pc = addr3, rather than pc += $addr3 . James, you'll need to compose it with additional instructions to have it match up with the subleq used in the example C++ libraries.
(This must be Ian's plan to slow subleq even further
)Quote from: Zahlen
The world's first pizza sold for crypto$ through an AE!
(Worldwide delivery within 60 mins, piping hot or a 2nd pizza free)
(Worldwide delivery within 60 mins, piping hot or a 2nd pizza free
)I got pizza for you.. worldwide delivery, i dunno
This will be the future of pizza delivery.
I also sort of thought there was gonna be some kind of vetting of people putting their names down for committees, where they would have to put in at least one post describing why they thought they were qualified to serve on a committee, what they wanted to accomplish there, blah blah blah, and um....we might actually VOTE IN A POLL to pick the top 5?
Instead it's just put your name down as a candidate and you're in? On as many committees as you want?
Instead it's just put your name down as a candidate and you're in? On as many committees as you want?
Yeah. I've been busy on contract work this week (and will be until April 1) so I'm not able to keep up as much as I'd like. There are lots of smart, competent folks like me who should be involved in these decisions but can't because they, you know, have jobs. We seem to be rushing to do things QUICKLY, instead of PROPERLY.
I'm ok with no vetting but
Candidates should sell themselves (okay, that sounded wrong
). e.g. Describe what they've done so far and link to it (even just contributing to discussion is fine). Explain what skills they have, and why they think they're a good fit for the committee they're interested in. They also need to confirm their availability. They don't need to reveal their identity (whether to the public, or just to someone trustworthy), but professional info like what trades they've been in, for how many years would help their case.i.e. convince everyone (meaning people who hang out in all the different forums) why you're a good choice, make it easy for folks to find info about what you've done, so that folks can make an informed choice.
Cross-posting from the main thread:
We could do it via AE: jef issues Base Regular, Base Large pizza etc. tokens, and Ham, Olives, Green Peppers, etc topping tokens and Thin Crust, Extra Cheese etc option tokens. A pizza-loving nxter customizes and picks up his Compound Pizza Token through the AE, sends jef an AM, and jef delivers.
The world's first pizza sold for crypto$ through an AE!
(Worldwide delivery within 60 mins, piping hot or a 2nd pizza free)
We should have a mechanism for grouping option tokens like this.
I wrote that only in half-jest. What does everyone think about such a grouping mechanism? Would it be practical? e.g. could it be used as proof of pizza purchase? With such tokens on hand, send them to someone as a /r/randomactsofpizza, or trade it for a real one for yourself whenever you like? What about for other items?
EDIT: Here's how *not* to give pizza: http://www.newsweek.com/chevron-gives-residents-near-fracking-explosion-free-pizza-229491
I'm happy to announce that TwinWinNerD has just bought some of my lovely stickers.
Yay!
77 NXT for 5 stickers+postage, its a bargain.
Which made me think: Is this transaction the first time someone has purchased a physical item in exchange for NXT ?
I can't believe no-one has done it before us, but I don't remember seeing anything earlier on in this thread.
I remember reading jefdiesel runs a pizza restaurant? Why wasn't this our first purchase?Yay!
77 NXT for 5 stickers+postage, its a bargain.
Which made me think: Is this transaction the first time someone has purchased a physical item in exchange for NXT ?
I can't believe no-one has done it before us, but I don't remember seeing anything earlier on in this thread.
We could do it via AE: jef issues Base Regular, Base Large pizza etc. tokens, and Ham, Olives, Green Peppers, etc topping tokens and Thin Crust, Extra Cheese etc option tokens. A pizza-loving nxter customizes and picks up his Compound Pizza Token through the AE, sends jef an AM, and jef delivers.
The world's first pizza sold for crypto$ through an AE!
(Worldwide delivery within 60 mins, piping hot or a 2nd pizza free
)We should have a mechanism for grouping option tokens like this.
I wrote that only in half-jest. What does everyone think about such a grouping mechanism? Would it be practical? e.g. could it be used as proof of pizza purchase? With such tokens on hand, send them to someone as a /r/randomactsofpizza, or trade it for a real one for yourself whenever you like? What about for other items?
EDIT: Here's how *not* to give pizza: http://www.newsweek.com/chevron-gives-residents-near-fracking-explosion-free-pizza-229491
I'm happy to announce that TwinWinNerD has just bought some of my lovely stickers.
Yay!
77 NXT for 5 stickers+postage, its a bargain.
Which made me think: Is this transaction the first time someone has purchased a physical item in exchange for NXT ?
I can't believe no-one has done it before us, but I don't remember seeing anything earlier on in this thread.
Yay!
77 NXT for 5 stickers+postage, its a bargain.
Which made me think: Is this transaction the first time someone has purchased a physical item in exchange for NXT ?
I can't believe no-one has done it before us, but I don't remember seeing anything earlier on in this thread.
I remember reading jefdiesel runs a pizza restaurant? Why wasn't this our first purchase?
We could do it via AE: jef issues Base Regular, Base Large pizza etc. tokens, and Ham, Olives, Green Peppers, etc topping tokens and Thin Crust, Extra Cheese etc option tokens. A pizza-loving nxter customizes and picks up his Compound Pizza Token through the AE, sends jef an AM, and jef delivers.
The world's first pizza sold for crypto$ through an AE!
(Worldwide delivery within 60 mins, piping hot or a 2nd pizza free
)We should have a mechanism for grouping option tokens like this.
is there anything that could be done to nxt to prevent high frequency trading? or would it not be possible anyway? just watching this http://documentary.net/wall-street-code-high-speed-trading/ and started thinking if nxt or any other crypto really did get mass adopted and wall street moved in.. they would just syphon off coins left right and centre... they may have allot of money to put into crypto.. but would you really want it there?
Traders within the Nxt network would still be limited by the block generation interval ("exactly" 60 secs when TF is first activated, this will decrease in future as infrastructure improves). They can't act on any information gained from one block until the next one.
But if they manage to set up some kind of proxy trading system outside of Nxt, and can all agree to just register the result within the Nxt network just in time for block generation... Normally I'd say this kind of