Topic: [ANN] [UBERCOIN] Working on a new coin. Will update this thread when completed. - page 2. (Read 12302 times)

Lol he just doesn't get the point does he.

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://bitcointalksearch.org/topic/m.2958176
https://bitcointalksearch.org/topic/m.2957272

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.

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.

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.

Good riddance.

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".

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.

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).

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.

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.

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.

Good luck. 

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.

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.

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

Nobody wants to work with me eh?

https://bitcointalksearch.org/topic/m.2954863

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

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?

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.

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.