smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:22:05 PM |
|
Furthermore, if the selected set of delegates is short lived, then any disruption caused by selecting a dishonest nodes in the previous set will be minimal, as transactions that failed which are deemed legitimate can simply be re-presented a short time later against a new set of delegates.
The higher the frequency of delegate election, the worse the service they can provide True (for various reasons such as ratios relating to propagation, denial-of-service, etc). - at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless.
False assumptions galore. Wait for the white paper. Amazing to me that what I invented seems so obvious in hindsight yet it isn't obvious to you all. Interesting. All discussion about delegation should stop now. Otherwise I will be forced to delete some posts. We are cluttering this thread with too much detail. Wait for the white paper then you will all understand. Continuing discussion here as Anonymint doesn't want to continue the discussion in his own thread.
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:27:53 PM |
|
It is definitely interesting to have a system that is DELEGATED yet requires no trust.
As part of the definition of the word delegated is to "entrust".
Seems like a poor word choice.
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
monsterer
Legendary
Offline
Activity: 1008
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:30:35 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW.
|
|
|
|
Fuserleer
Legendary
Offline
Activity: 1064
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:33:07 PM Last edit: September 09, 2015, 09:50:31 PM by Fuserleer |
|
A point worth considering: If the delegated set is fixed over a prolonged period of time, then its not trustless. If the delegate set changes constantly as the result of some random function, then it may be trustless depending on how large the source set is.
Interesting point. How does it change the issue of trust even if the delegating parties change randomly? The delegating parties themselves for iteration n still are to be trusted right? It reduces the exposure of the system to dishonest nodes, as providing that the function output that determines the set selection is random, these dishonest nodes will never know when they will have an opportunity to be dishonest. This then requires these nodes to be online constantly in the chance that they do get selected in the next round of delegates. If the selection set is sufficiently large, and the function output is random (or close to), then the time between subsequent selection may be quite long, thus acting as a discouragement due to costs. Furthermore, if the selected set of delegates is short lived, then any disruption caused by selecting a dishonest nodes in the previous set will be minimal, as transactions that failed which are deemed legitimate can simply be re-presented a short time later against a new set of delegates. You can increase resilience further if you delegate the work to ALL selected delegates instead of just one or a few of them. Then they all perform the same work and you can think about using the output from that as a basis for consensus. You have to consider Sybils and other things too, but the basic philosophy is as above. Did I explain clearly? :| Not sure lol Okay let's talk about the delegating party. Supposing they are random then it is like a musical chairs type thing. Some times certain parties will play the delegator and some the delegat-ee. But the delegator needs to be trusted in some form as they need to delegate correct tasks (within the specs of the system). Who decides who the delegator is? If it is random don't you think that a malicious delegator could exist at some point? Ok, so to circumvent possible dishonest delegators you simply ensure that to become a delegator involves some honest action, better still if there is some cost involved. So for example, in eMunie, the delegator is the party that makes the transaction, which is for all intents and purposes an honest action. If the transaction is not for an honest intent, transactions have fees, so there is a cost associated with it. The future delegate set is determined from recent transactions, and the process of making transactions essentially random. If I have a payment to make, I might make it now, or I might decide to do it later on, or maybe I don't do it all. As I mentioned in the other thread, you have to consider Sybil and other similar attacks that attempt to reduce the random entropy of delegate selection, but those are for another discussion I think and would distract from the core concepts we're investigating here.
|
|
|
|
traumschiff
Legendary
Offline
Activity: 1498
Merit: 1001
180 BPM
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:33:37 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
|
|
|
|
smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:33:56 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW. Is there any middle ground in your mind?
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
monsterer
Legendary
Offline
Activity: 1008
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:38:35 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW. Is there any middle ground in your mind? Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate. edit: and whenever you combine anonymity with trust, you are asking for trouble IMO IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible.
|
|
|
|
Fuserleer
Legendary
Offline
Activity: 1064
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:39:34 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW. Network latency isn't an issue if you apply some simple ruling to delegate selection. You are correct that it is impossible for all nodes to know the current set of delegates if they are selected below a certain interval, in real time, due to CAP theorem. However, if you base the set selection on an offset of time in the past, say 60 seconds, you can be sure that the majority of the network has information on transactions up to 60 seconds ago. Thus you select the delegates from a set between say T-60 and T-120 (if you want a set duration of 1 minute). This approach allows you to have per second delegate set generation, as it provides a "sliding window" over time.
|
|
|
|
Fuserleer
Legendary
Offline
Activity: 1064
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:43:25 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
Heh I say that all the time "wait for more documents from me!" Then I end up getting into a deep technical discussion soon after ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
ion.cash
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:45:20 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW. Is there any middle ground in your mind? Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate. edit: and whenever you combine anonymity with trust, you are asking for trouble IMO IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible. You didn't answer his astute question. And your dichotomous assumptions are very myopic. You do not entertain all the possibilities. You are going to receive a very big surprise when you read my entire white paper. I told everyone that I am not ready to discuss my design at this time. When I am ready, we will in great detail. I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct. P.S. no personal offense intended. I will appreciate the debate and discussion with you at the appropriate time. I allowed you to push me for more information and discussion than is advisable at this time for my project. Add: I really appreciate all the interest in this topic. It is an important one.
|
|
|
|
smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:50:03 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
Yeah I have to say that was uncalled for. Why not just wait until it is ready then announce. Sounds like he enjoys the attention.
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
monsterer
Legendary
Offline
Activity: 1008
Merit: 1007
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:50:59 PM |
|
I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.
You realise you sound like John Connor?
|
|
|
|
smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:52:29 PM |
|
- at one extreme, the service is completely trust based and very efficient and at the other extreme there is no advantage at all to having delegates but they are completely trustless. Here is my reasoning: Extreme lower end100% trust based, permanent list of delegates - this is the ripple labs model. They are an unchanging set, never disagree with each other and can provide transaction finality in under 3 seconds per block. Extreme upper endEver changing list of delegates, where network latency entirely governs the current state of the network and because of that you have to wait for 50% of them to come to a consensus. Because of the ever changing set, you need sybil resistance and now you've basically got trustless POW. Is there any middle ground in your mind? Personally, I really dislike trust based models in crypto-currencies - trust is for the centralised banking system we've all come to know and hate. edit: and whenever you combine anonymity with trust, you are asking for trouble IMO IMO 'Trustless' is a completely revolutionary concept which deserves to be applied to anything and everything possible. You didn't answer his astute question. And your dichotomous assumptions are very myopic. You do not entertain all the possibilities. You are going to receive a very big surprise when you read my entire white paper. I told everyone that I am not ready to discuss my design at this time. When I am ready, we will in great detail. I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct. P.S. no personal offense intended. I will appreciate the debate and discussion with you at the appropriate time. I allowed you to push me for more information and discussion than is advisable at this time for my project. Add: I really appreciate all the interest in this topic. It is an important one. Please go elsewhere given you already asked people not to discuss delegation and this thread is simply about ion delegation. Thanks ![Kiss](https://bitcointalk.org/Smileys/default/kiss.gif)
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
smoothie (OP)
Legendary
Offline
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:53:53 PM |
|
I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.
You realise you sound like John Connor? Not to be mean, but posting an observation, Anonymint has a god complex. He really thinks highly of himself. The word humble does not appear to be in his mindset. Carrying on discussion about delegation...
|
███████████████████████████████████████
,╓p@@███████@╗╖, ,p████████████████████N, d█████████████████████████b d██████████████████████████████æ ,████²█████████████████████████████, ,█████ ╙████████████████████╨ █████y ██████ `████████████████` ██████ ║██████ Ñ███████████` ███████ ███████ ╩██████Ñ ███████ ███████ ▐▄ ²██╩ a▌ ███████ ╢██████ ▐▓█▄ ▄█▓▌ ███████ ██████ ▐▓▓▓▓▌, ▄█▓▓▓▌ ██████─ ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌ ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─ ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩ ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀ ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀` ²²² ███████████████████████████████████████
| . ★☆ WWW.LEALANA.COM My PGP fingerprint is A764D833. History of Monero development Visualization ★☆ . LEALANA BITCOIN GRIM REAPER SILVER COINS. |
|
|
|
ion.cash
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:54:51 PM |
|
I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.
You realise you sound like John Connor? I am not selling anything. There is no coin yet. VNL is a coin that is already on the market. In the opening post of the thread I created, it clearly states that I would not be discussing the consensus design at this time, and that the purpose of making a thread now was to get a vote on the naming and to show some code to prove I am real and to potentially solicit some other developers to help. I apologize if I am I following what I wrote in my opening post. I should apologize for trying to maintain consistency between what I write and what I do. You of course are welcome to discuss consensus designs and delegation in your own threads. I just won't be participating further at this time. I will soon when my implementation has reached the point where I can publish the white paper. Again no personal offense intended. Carry on without me. Why can't we have mutual respect? Am I a God to ask that I can be consistent? Come on stop acting like 5 year olds. We are more mature than that.
|
|
|
|
Fuserleer
Legendary
Offline
Activity: 1064
Merit: 1020
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 09:59:16 PM |
|
I am not going to be following the discussion in this thread at this time. Any who continue to make more false and myopic statements, that doesn't mean you are correct.
You realise you sound like John Connor? Not to be mean, but posting an observation, Anonymint has a god complex. He really thinks highly of himself. The word humble does not appear to be in his mindset. Carrying on discussion about delegation... He does indeed, I've expressed this to him a couple of times. I can't deny the fact that he is very smart, and weirdly, I do respect his position on a lot of topics. Problem is I've seen many times that those kind of character traits cause the undoing of that individual, even though they have the capacity to do something truly great...
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 10:28:11 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
Mark this down for the history books. I agree with traumschiff. Seems like the only purpose is to hype vaporware. I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though.
|
|
|
|
r0ach
Legendary
Offline
Activity: 1260
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 10:35:39 PM |
|
Not to be mean, but posting an observation, Anonymint has a god complex.
He does indeed, I've expressed this to him a couple of times. I can't deny the fact that he is very smart, and weirdly, I do respect his position on a lot of topics. Problem is I've seen many times that those kind of character traits cause the undoing of that individual, even though they have the capacity to do something truly great... That's the entire point of reading an Anonymint thread, it's going to be exciting, and maybe even a little bit frightening.
|
|
|
|
ion.cash
Newbie
Offline
Activity: 28
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 10:44:09 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
Mark this down for the history books. I agree with traumschiff. Seems like the only purpose is to hype vaporware. I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though. I started a thread where I could update the public on progress of the development, with first order of business being getting a vote on the proposed name and the next step I said I would be uploading some code. Then from there on updates on the progress. I don't understand what is wrong with making a thread for that purpose to track the early stage development of a coin? So that the community of people who are interested in the progress can be updated. And so issues in the development stage can be discussed. First step of development interaction with the public is on the choice of a name. Please enlighten me?
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
September 09, 2015, 10:46:08 PM |
|
I'm bothered by the fact that he opens a thread for his project where he refuses to discuss certain questions in detail (even goes as far as threatening with deletion) because "wait for the whitepaper".
I don't see the point of the thread.
Mark this down for the history books. I agree with traumschiff. Seems like the only purpose is to hype vaporware. I don't think it is really malicious but more driven by enthusiasm and being a bit impatient to wait until it's actually done (at least in part) before discussing it. The effect is similar though. I started a thread where I could update the public on progress of the development, with first order of business being getting a vote on the proposed name and the next step I said I would be uploading some code. Then from there on updates on the progress. I don't understand what is wrong with making a thread for that purpose to track the early stage development of a coin? Please enlighten me? Mostly the discussion, I suppose, where you answer questions and FUD but without being able to give any substantive answers (I'm not criticizing your reasons for that). My suggestion is to lock the thread and bump it when you have substantive updates. Maybe reopen on a more permissive/permanent basis when there is actual substance to discuss (code, white papers, slides, etc.) But if the idea was just to discuss the name (first order of business as you say), that's certainly reasonable but then the off topic (to the name) posts should be deleted and not replied with non-substantive replies.
|
|
|
|
|