[ANN] [UBERCOIN] Working on a new coin. Will update this thread when completed.

[jlspartz]

Do you go to interviews and piss off the management and get kicked out of the office then stand on the sidewalk and tell everyone walking by how terrible their knowledge of interviewing new employees is compared to when you conduct interviews?

The last two guys I worked for (who created Fractal Design Painter, which became Corel Painter) are high geniuses (Caltech grads) and one could memorize a page of a phone book by looking at it.

I subsumed my ego because they were at least as smart as me, and smarter in some areas at that time (I was young, they were older).

I haven't needed to work for anyone else since then. I am prolific enough at creating projects that succeed.

Make a separate thread where you will present your ideas about your alt coin, this whole debate is counter productive and resource waisting.
Let them do the best they can and you can offer your coin too. Then it is the best of the two (and not only) that will succeed. I will watch both projects with great interest.
I try to persuade some people to fund a group of programmers in order to make an alt. Maybe we can find a formula to get something good!
I am interested on your opinion about MC2 (Netcoin), PeerCash and Bitcoin2. Links tomorrow cause I have to sleep!

Peace to all and we need positive vibes people, stop waisting ur resources...

Post the links in my thread please, so we don't piss off these UBER guys more:

https://bitcointalk.org/index.php?topic=160612.new#new

Agreed let them go do theirs. We very much need a coin that addresses the high-priority issues I have enumerated. Looks like I have to do it by myself.

I have a 168 IQ.  Am I someone in the intellectual classification to listen to when I say you are a douche on a whole different level?  It's not your programming skills or your "insightful" comments that stand out.  Really!  I must laugh at those thinking they are so high they can't talk to others like you.  Intelligence speaks vacuums about your character.  There are prodigies in skills you can waste a lifetime mastering, and influential individuals who can move millions through speech alone.  Humility is one of the most important "big picture" concepts in discerning ones.

[AnonyMint]

I have a 168 IQ.  Am I someone in the intellectual classification to listen to when I say you are a douche on a whole different level?  It's not your programming skills or your "insightful" comments that stand out.  Really!  I must laugh at those thinking they are so high they can't talk to others like you.  Intelligence speaks vacuums about your character.  There are prodigies in skills you can waste a lifetime mastering, and influential individuals who can move millions through speech alone.  Humility is one of the most important "big picture" concepts in discerning ones.

Bla bla bla. Wake me up when you have some technicals to discuss that matter. Meanwhile back to coding...

If you were 168 IQ, you would recognize something which you apparently have not.

[AnonyMint]

I am interested on your opinion about MC2 (Netcoin), PeerCash [PPC] and Bitcoin2. Links tomorrow cause I have to sleep!

Netcoin has promise, I would like to see it succeed...

Another example of your technical myopia.

The Netcoin white paper admits their methods do not stop ASICs (FPGAs) long-term. The only way to defeat ASICs (FPGAs) over the long-term is to make RAM memory the largest cost component.

When analyzing these peer voting systems (emunie, Decrits, PPC, Netcoin), I always look to where the input entropy can be gamed. They ALWAYS have a flaw and can be attacked. In the case of Netcoin, its PoS contribution can be attacked because a peer can target its peer key by the transactions it includes in the block which determines the hash that selects which peers can vote. Enough said. They don't work!

I read that someone wrote that Gavin Andresen wrote that PoS blocks (perhaps w.r.t. to PPC not Netcoin) can be DDoS with fake PoS blocks. Haven't delved deeper yet into that point.

On the marketing side of the equation, netcoin doesn't own the .com and .org.

[jasinlee]

Do you still hang around your ex gfs house talking to her door or do you respect the 100 ft requirement the court put into place and yell from across the street?

[AnonyMint]

Nobody wants to work with me eh?

https://bitcointalk.org/index.php?topic=267522.msg2954863#msg2954863

Observe how the guy who created MemoryCoin operates. It is a lesson to you juveniles on how you get 'er done in open source.

[BigJohn]

Anony, do you have your own thread about these issues?

[AnonyMint]

Anony, do you have your own thread about these issues?

It is not all organized in one place. Best suggestion for now is to click my name, then click "recent Posts" then you can read summaries and click only on posts which are relevant for you.

And I hope this is my last comment in this thread, because the OP author doesn't want my involvement in his thread.

When there exists code and a coin, there will be a dedicated thread for it.

[NiccoloMac]

Glad you got the subtle hints that you were unwanted.

As for the coin:

We have completed the items marked off the list. If anyone has further items they see missing post them please so I can tie it all together as we move along.

[AnonyMint]

Good luck. 

[digitalindustry]

Wow.  You know , I'm glad I witnessed that .

I tried to explain to him that open source means acumulitive ideas , he seems to have malfunctioned somewhere along the way .

If Anony you are a sock puppet computer program , your code has malfunctioned.

Anonymity goto kill process.

[btc4ever]

Please add the ability to determine fee amount before sending with the jsonrpc API.

Something like:

 preparesend( toaddress, amount ) returns { txid_prepared, fee }
 sendprepared( txid_prepared );

It is ok if txid_prepared expires after 1 minute or something, or if sendprepared fails if it is no longer able to give the same fee.

Even calcsendfee( toaddress, amount ) with no guarantee of same fee when sendtoaddress is called would be better than nothing.

Right now it is a big headache that applications cannot know fee in advance of sending and afterwards it is just a surprise, so the application cannot make any intelligent decisions.  Sometimes the fee is really big if there were a lot of transaction inputs, but the API provides no high level insight or control over that.

Related to this would be adding the coincontrol patch, to be able to control which keys are sent from.  and expose it in the RPC API.

[NiccoloMac]

Apparently I should have a god complex to gain respect. I should add that to the to do list.

Yes, open source should be a community effort, not this I know what to do because I am a genius and I said so attitude.

Perhaps next if no one has further suggestions, we can get suggestions for the wallet look/design. QT is actually very easy to change so we can do quite a few adjustments or keep most of QT as it is now.

Also adding fee adjustment options to OP.

[stbgefltc]

Please add the ability to determine fee amount before sending with the jsonrpc API.

Something like:

 preparesend( toaddress, amount ) returns { txid_prepared, fee }
 sendprepared( txid_prepared );

It is ok if txid_prepared expires after 1 minute or something, or if sendprepared fails if it is no longer able to give the same fee.

Even calcsendfee( toaddress, amount ) with no guarantee of same fee when sendtoaddress is called would be better than nothing.

Right now it is a big headache that applications cannot know fee in advance of sending and afterwards it is just a surprise, so the application cannot make any intelligent decisions.  Sometimes the fee is really big if there were a lot of transaction inputs, but the API provides no high level insight or control over that.

Related to this would be adding the coincontrol patch, to be able to control which keys are sent from.  and expose it in the RPC API.

It is possible, but as you mentionned, there is no guarantee whatsoever that the result will be right. Fee size is determined by a couple factors, notably, age of inputs, number of inputs, but also, and that is the most unpredictable part, current block size. Transaction fees get more expensive as block size increases with the number of transactions being pushed on it.

Edit. Instead of using a temporary txid that would expire, another idea could be to return raw transaction data that is ready to be passed to sendrawtransaction. You'd get the added benefit of your prepared tx not expiring (as long as its inputs are not spend anywhere else).

[hypersire]

NiccoloMac - Just wondering if you will be trying to get the coin on an exchange asap or will it just be mining at first? It's pretty easy to get a coin onto Cryptsy.

[AnonyMint]

Apparently I should have a god complex to gain respect. I should add that to the to do list.

Yes, open source should be a community effort, not this I know what to do because I am a genius and I said so attitude.

I wrote "good luck " and you can't let it go that you were too stupid to think that "side hashing" would work. You just keep going on and on, because you feel insecure. Get over it.

I said "good luck".

[stbgefltc]

Good riddance.

[stbgefltc]

Please add the ability to determine fee amount before sending with the jsonrpc API.

Something like:

 preparesend( toaddress, amount ) returns { txid_prepared, fee }
 sendprepared( txid_prepared );

It is ok if txid_prepared expires after 1 minute or something, or if sendprepared fails if it is no longer able to give the same fee.

Even calcsendfee( toaddress, amount ) with no guarantee of same fee when sendtoaddress is called would be better than nothing.

Right now it is a big headache that applications cannot know fee in advance of sending and afterwards it is just a surprise, so the application cannot make any intelligent decisions.  Sometimes the fee is really big if there were a lot of transaction inputs, but the API provides no high level insight or control over that.

Related to this would be adding the coincontrol patch, to be able to control which keys are sent from.  and expose it in the RPC API.

It is possible, but as you mentionned, there is no guarantee whatsoever that the result will be right. Fee size is determined by a couple factors, notably, age of inputs, number of inputs, but also, and that is the most unpredictable part, current block size. Transaction fees get more expensive as block size increases with the number of transactions being pushed on it.

Edit. Instead of using a temporary txid that would expire, another idea could be to return raw transaction data that is ready to be passed to sendrawtransaction. You'd get the added benefit of your prepared tx not expiring (as long as its inputs are not spend anywhere else).

It just struck me that by implementing coin control features (lock/unlock coins), inputs could be locked when a transaction is prepared as you describe it, you no longer have the issue the used inputs being possibly spent elsewhere. I guess that's another feature niccolomac can add to the list.

[Fuserleer]

Simple fact is, arguing about something never got anything done.

It amuses me that these in the "know" never actually have anything substantial to show....too much time spent procrastinating about what they can do, instead of backing it up IMO.

Basically everyone can say they have the biggest cock, but all bets are off until the cocks are on the table.

[stbgefltc]

Simple fact is, arguing about something never got anything done.

It amuses me that these in the "know" never actually have anything substantial to show....too much time spent procrastinating about what they can do, instead of backing it up IMO.

Basically everyone can say they have the biggest cock, but all bets are off until the cocks are on the table.

Well, he does have CoolPages. But I'm gonna stop there, I said I was out of this argument :p

UPDATE : Regarding the fee calculation, the following RPC calls would be nice to have :

preparetransaction(sendAddress, amount, maxFee, lockInputs)
Prepares a transaction by using the following parameters :
sendAddress : b58 encoded destination address
amount : amount of coins to send.
maxFee : maximum fees the sender is willing to pay, or -1 to specify no limit.
lockInputs : whether the inputs used to prepare the transaction should be locked. This feature is mostly for wallets with high volumes of outgoing transactions, to ensure coins stay available until the
Return value : a JSON object { hex: "signed tx raw data", fee: "0.1" }, where hex contains the signed raw data for the transaction , ready to be passed to sendrawtransaction. fee contains the fee amount that has been included in the transaction when this fee does not exceed the user specified limit. If the required fee exceeds the user specified limit when he passed a positive value to maxFee, an error object is returned with a message stating the required transaction fees exceed the user's limit.

canceltransaction(hex)
Cancels a prepared transaction by using the following parameters :
hex : raw data of a previously prepared transaction.
Return value : boolean indicating success or not.

This call would be required in case preparetransaction was called with lockInputs = true.

If the user is satisfied with the prepared transaction and the applied fees, he can then submit the hex data to sendrawtransaction to broadcast his transaction on the network and get the transaction's ID.

[AnonyMint]

Simple fact is, arguing about something never got anything done.

Agreed:

http://esr.ibiblio.org/?p=3514 ("Those Who Talk, Don't Build")

Nevertheless, there are many mistakes being made by the people who run fast to build yet either don't really know what they are doing or are moving too fast to find out:

https://bitcointalk.org/index.php?topic=227287.msg2958176#msg2958176
https://bitcointalk.org/index.php?topic=267522.msg2957272#msg2957272