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

[jasinlee]

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

[digitalindustry]

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

Ha ha that's right Anony and some of those things fail spectacularly , and then , guess what ?

The earth revolves around the sun again , and the sun around its spiral and so on.

Did you have a point ? Or are you really a program of which the name accidentally has a misplaced "n"  guess where.

My IQ can't be measured Annoymint , but I can only just read one yellowpages page at a time.  Generally word by word , and if its the business section I like , I can usually remember the interesting business , but only usually when I'm looking for one.

[AnonyMint]

So "birdbrain" we shouldn't try to fix them before they fail? 

What is YOUR point?

[NiccoloMac]

So "birdbrain" we shouldn't try to fix them before they fail? 

What is YOUR point?

Get a clue, no one wants to hear your opinions anymore because you are a douche. Go develop your own coin, you spend so much time posting on here, how do you NOT have time to develop anything? Your narcissism wont let you exit without the last word? Ok reply to this post like I know you will, and then stay gone knowing we wont reply just so you will go away.

[stbgefltc]

You guys just don't understand how much you need him. You are doomed to fail without his help... 

[digitalindustry]

So "birdbrain" we shouldn't try to fix them before they fail?  

What is YOUR point?

quite simply no , you fool, no.

and especially if the "fixing" is resulting in no action therefore no productive capacity, its a void/null equation.

when we fail , if we fail, the process is fixing , can't you see what is happening in front of you?

When things fail great things happen, humans work better this way.

the more open the environment the better and the more open the information system the better., the failure, the better the failure the better the system.

this is evolution accelerated.


** don't come back to me with "computer modeling" or "testing" its redundant , humans are not numbers. you keep missing this , maybe your super IQ is causing a social human fragmentation ?

*** the all seeing and all hearing "Government" that you so fear,  could spend billions , Trillions in today's numbers,  in fiat and not get the same accelerated result , they could train huge numbers of monkeys to dance and tap sticks instead, of which, i completely agree with...but sadly there is no time for that , there is of course , wars to fight.

[AnonyMint]

The characters here are almost as entertaining as Monty Python's Flying Circus.  

Inspiring to see a group taking form (out of the conscious flog) with great unconscious comedic talent.

Noting a particularly apt likeness to the Meaning of Life or Life of Brian.

[btc4ever]

I like it.  I figure that the QT client must have something similar in it, as it is able to present a confirmation dialog to the user before sending that shows the fee, and the send can be cancelled at that point.   So it would seem that the code exists, and just needs to be exposed in the RPC api.   Your proposal seems good to me.

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.

[digitalindustry]

Ok back to the topic ,

A little annoying pet hate of mine , not sure if it was brought up.

When sending the total balance of a wallet. ...

So when one is about to send a transaction , then the client dutifully informs one of the fee.

This is all rather silly and redundant , just ask if you accept the fee , then automatically deduct it.

What occurs now is the stopping , the having to deduct the fee ,  revise the figure and resend, why not if you are sending the   total  Balance  just deduct the fee and let the transaction happen.  If agreed .

[digitalindustry]

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.

Maybe its better to ask what the issue around fees is ?

Is it the unpredictable nature ?

Or

The fee increase and number  ?

Because perhaps a simpler way is a lower overall fee structure  and either an inflation or stake structure.

I'm in agreement that any distributed currency will find fair value even with an inflation model , this is as simple as the day is long .

Security is another concern , but to tell you the truth I don't see it as a large one well not as large as some others do.

There can be such things as " rolling security"  this is not dissimilar to an accepted amount of security balanced with use and other factors .

[stbgefltc]

Yeah, their unpredictable nature is what's causing problems. They increase as the number of transactions to be included in the next block increases. We could revise the system, but don't forget that it's a valuable anti-DDoS tool : the rising cost prevents from pushing spam transactions on a block, as it makes the attack expensive.

[AnonyMint]

Because perhaps a simpler way is a lower overall fee structure  and either an inflation or stake structure.

No (or too low) tx fee means there is no (or too low) cost to spamming the transactions.

Security is another concern , but to tell you the truth I don't see it as a large one well not as large as some others do.

There can be such things as " rolling security"  this is not dissimilar to an accepted amount of security balanced with use and other factors .

Chaos. Please implement your sometimes secure coin. My popcorn is in the microwave.

A single-rate tx fee is less chaotic.

[stbgefltc]

The characters here are almost as entertaining as Monty Python's Flying Circus.  

Inspiring to see a group taking form (out of the conscious flog) with great unconscious comedic talent.

Noting a particularly apt likeness to the Meaning of Life or Life of Brian.

And you have no idea how much fun I had with you. You're great, man, just great ! A little poke, and you're here, back on the tracks, defending your higher order intelligence.

Speaking of unconscious talent, you're a rock star in that area

[stbgefltc]

I like it.  I figure that the QT client must have something similar in it, as it is able to present a confirmation dialog to the user before sending that shows the fee, and the send can be cancelled at that point.   So it would seem that the code exists, and just needs to be exposed in the RPC api.   Your proposal seems good to me.

Yeah, the QT part tries to send the tx, but the wallet raises an error when fee is not high enough. So the UI then asks the user to accept min. fee, which is calculated by the wallet, at which point it retries to send the transaction with proper fees when the user accepts. Porting that flow to RPC is no biggie, but the logic is a bit different.

 You have to keep in mind that the transaction, in the UI, will go through if no fee is required. Here, we do not want the transaction to go through. I don't remember the exact code, there might be some refactoring in order to separate actual sending from fee calc, but it's still no biggie

[NiccoloMac]

Updated OP.

[klee]

Is this dead?

[Duffer1]

Is this dead?

I hope not

[jasinlee]

The things we asked for will likely take a while to produce.

[klee]

The things we asked for will likely take a while to produce.

Sure, I just wanted to know if the guys are working on it or moved to other things!

[provenceday]

The things we asked for will likely take a while to produce.

Sure, I just wanted to know if the guys are working on it or moved to other things!

maybe this one

https://bitcointalk.org/index.php?topic=701621.0