[DVC]DevCoin - Official Thread - Moderated - page 289.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: Unthinkingbit on December 27, 2013, 03:48:24 PM

Quote from: cyke64 on December 26, 2013, 02:09:19 AM

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

Thank you for your excellent code report, you get 12 shares:

The last remaining code report bounty is 6 shares.

You try out the java installer? I will create a sorceforge so
I can host the releases.

Unthinkingbit

hero member

Activity: 935

Merit: 1015

Quote from: cyke64 on December 26, 2013, 02:09:19 AM

..
Here's a detailled code report.
I took ALL the commits made by Twobits or twobits in the devcoin client.
I made a list from all the changes made by twobits and compare with the code of Sidhujag.

Thank you for your excellent code report, you get 12 shares:
https://raw.github.com/Unthinkingbit/charity/master/bounty_31.csv

The last remaining code report bounty is 6 shares.

Quote from: sidhujag on December 27, 2013, 11:17:47 AM

The default rpcport is a setting in the conf file that I oerwrote I can connext so its working. I will change this but its only useful for proxies and if conf file doesnt specify rpcporr in the firet place...

Otherwise we just need to send a few coins back forth to confirm fees and mining merged works.

I'm glad this will be changed. Even if it's overwritten, it's still good to have it the same as the documentation to prevent confusion.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: markm on December 27, 2013, 11:28:21 AM

Quote from: sidhujag on December 27, 2013, 11:17:47 AM

The default rpcport is a setting in the conf file that I oerwrote I can connext so its working. I will change this but its only useful for proxies and if conf file doesnt specify rpcporr in the firet place...

Otherwise we just need to send a few coins back forth to confirm fees and mining merged works.

I never use conf files, except for those ancient multicoin-based coins like the old GeistGeld and Tenebrix.

If for some reason I need to use a port other than the default I put it on the commandline in my start-the-daemon script.

Usually I do not put it on the commandline though because to do so I'd have to go digging into the source-code to discover what the heck the default port actually is, since that is the port I'd put there anyway unless it was one of those stupid crapcoins that forgot to change its port from whichever coin it was cloned from; and those coins I usually try to avoid.

-MarkM-

Ya that was i0coin ports I scanned Important places left that one out.. Should change...

Anyone have experience with maven? Having a heck of a time building
bitcoinj with android wallet ootb.

markm

legendary

Activity: 2940

Merit: 1090

Quote from: sidhujag on December 27, 2013, 11:17:47 AM

The default rpcport is a setting in the conf file that I oerwrote I can connext so its working. I will change this but its only useful for proxies and if conf file doesnt specify rpcporr in the firet place...

Otherwise we just need to send a few coins back forth to confirm fees and mining merged works.

I never use conf files, except for those ancient multicoin-based coins like the old GeistGeld and Tenebrix.

If for some reason I need to use a port other than the default I put it on the commandline in my start-the-daemon script.

Usually I do not put it on the commandline though because to do so I'd have to go digging into the source-code to discover what the heck the default port actually is, since that is the port I'd put there anyway unless it was one of those stupid crapcoins that forgot to change its port from whichever coin it was cloned from; and those coins I usually try to avoid.

-MarkM-

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: Wekkel on December 27, 2013, 11:16:33 AM

Ok, tested the payment fees again. When sending 8 DVC, no message from my client (it sends the payment right away). At 7 DVC, the client informs me that a 1.2 DVC fee will apply. I have not investigated further into decimals.

Ya 1.2 dvc fees are normal or 0.2 dvc fees depends on transaction..

sidhujag

legendary

Activity: 2044

Merit: 1005

The default rpcport is a setting in the conf file that I oerwrote I can connext so its working. I will change this but its only useful for proxies and if conf file doesnt specify rpcporr in the firet place...

Otherwise we just need to send a few coins back forth to confirm fees and mining merged works.

Wekkel

legendary

Activity: 3108

Merit: 1531

yes

Ok, tested the payment fees again. When sending 8 DVC, no message from my client (it sends the payment right away). At 7 DVC, the client informs me that a 1.2 DVC fee will apply. I have not investigated further into decimals.

sidhujag

legendary

Activity: 2044

Merit: 1005

markm

legendary

Activity: 2940

Merit: 1090

Unthinkingbit's original approach to the second to the post problem was to award bounties to the first few of a thing instead of only to the first.

I have seen that for pretty much all the bounties that I have noticed. Is that not the case with the ATM bounty or is that approach not a good one?

-MarkM-

cyke64

newbie

Activity: 15

Merit: 0

Hunterbunter

hero member

Activity: 994

Merit: 1000

Quote from: advanced on December 26, 2013, 04:45:13 PM

Let me put you through an example: Say I want to build a DVC ATM machine (ndr: which I do want, and I have skills, tools, people, and time ) .
It takes a lot of effort, work, components, people and skills. There is a 96 shares pending bounty on it.
But before digging into the project and starting taking my time out of other paid projects, buy materials and hire people I want to make some math.
The problem is.... I can't! 96 shares could be anything between 2k$ and 25k$ by the time I'm done. Right?
It doesn't make sense. I created a certain value for the community and I would like to receive a fair value back. Not just a random number. Don't you think so?

At some point, 96 shares may be worth between $25k and $250k, or $250k-$2.5m. The first person/group who can produce the bounty economically will do so, including or excluding the bounty in their business plan - which is a risk in itself, since if they're second to market, they must rely on market demand alone (or perhaps a reduced bounty). There is no guarantee the price will ever get that high, but the point in time it is produced will be the moment that someone finds the risk acceptable and goes for it.

weisoq

hero member

Activity: 720

Merit: 500

I've only ever noticed a flat 1 dvc fee. Perhaps with very low sums it differs. Makes sense to not have any transactions actually prevented as risks having to change code again in the event that price rose significantly or micro-payments become very popular.

markm

legendary

Activity: 2940

Merit: 1090

Quote from: Unthinkingbit on December 27, 2013, 01:27:35 AM

Quote from: markm on December 26, 2013, 11:37:31 PM

..

Quote

Dust protection has to be a tiny fee on all transactions, otherwise an attacker could send medium amounts to himself many times. I don't know if the code was enforcing fees on all transactions, but that was my intent.

Oh okay, I guess I just had not noticed the fee since it wasn't actually saying anything about it (like this will cost X in fees, send anyway? or whatever).

I guess bitcoin only used coin age to prevent the sending to yourself around in circles approach to spamming/bloating the blockchain.

Not sure why we thought was wasn't enough to work for devcoin too though.

(Maybe bitcoin didn't have the coin-age parts back in those days?)

I didn't know it was using coin age to stop that. In any case, even if coin age can stop dust, free transactions are still a cost on the network.

Absolutely. Bitcoin had been promoted as no transaction fees so kind of had to use coin-age instead of all transactions having a fee.

We don't advertise free transactions hopefully so aren't thusly constrained.

-MarkM-

Unthinkingbit

hero member

Activity: 935

Merit: 1015

Quote from: markm on December 26, 2013, 11:37:31 PM

..

Quote

Dust protection has to be a tiny fee on all transactions, otherwise an attacker could send medium amounts to himself many times. I don't know if the code was enforcing fees on all transactions, but that was my intent.

Oh okay, I guess I just had not noticed the fee since it wasn't actually saying anything about it (like this will cost X in fees, send anyway? or whatever).

I guess bitcoin only used coin age to prevent the sending to yourself around in circles approach to spamming/bloating the blockchain.

Not sure why we thought was wasn't enough to work for devcoin too though.

(Maybe bitcoin didn't have the coin-age parts back in those days?)

I didn't know it was using coin age to stop that. In any case, even if coin age can stop dust, free transactions are still a cost on the network.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: markm on December 26, 2013, 11:37:31 PM

Quote from: Unthinkingbit on December 26, 2013, 11:34:08 PM

Quote from: markm on December 26, 2013, 10:53:15 PM

We have always had free transactions, I think, haven't we?

Or maybe it was just taking a fee without telling me?

I have had sends to Vircurex take many hours to get confirmations, I had always figured that was because they included no fee.

Dust protection is supposed to force a few on tiny tiny transactions, not slap on a tiny fee on all transactions.

I am not positive though.

But I routinely all along have sent transactions of millions of coins at a time without seeing any mention of any fees.

Dust protection has to be a tiny fee on all transactions, otherwise an attacker could send medium amounts to himself many times. I don't know if the code was enforcing fees on all transactions, but that was my intent.

Oh okay, I guess I just had not noticed the fee since it wasn't actually saying anything about it (like this will cost X in fees, send anyway? or whatever).

I guess bitcoin only used coin age to prevent the sending to yourself around in circles approach to spamming/bloating the blockchain.

Not sure why we thought was wasn't enough to work for devcoin too though.

(Maybe bitcoin didn't have the coin-age parts back in those days?)

-MarkM-

Essentially they just enabled isdust function which throws the tx away or some other weird logic inside wallet.cpp that increases the fee until it gets high enough to be acceptable and another that adds fees if your close to the creation of a block?

since btc dust in devcoin codebase turns out to be under 526 uDVC medium amount are still very low in terms of btc or usd so we need to add a valid fee to deter devcoin dust.. This is valid on something like under a few hundred devcoins.. im seeing this howver wekkel is reporting he doesnt get the confirmation for 1.2dvc fee on small transactions like 10dvc like I do.. it sent it for 0.2 dvc fee.. Id like 1.0.6 to be used be a few ppl to ensure it works as I expect and like it worked on my machine.

markm

legendary

Activity: 2940

Merit: 1090

Quote from: Unthinkingbit on December 26, 2013, 11:34:08 PM

Quote from: markm on December 26, 2013, 10:53:15 PM

We have always had free transactions, I think, haven't we?

Or maybe it was just taking a fee without telling me?

I have had sends to Vircurex take many hours to get confirmations, I had always figured that was because they included no fee.

Dust protection is supposed to force a few on tiny tiny transactions, not slap on a tiny fee on all transactions.

I am not positive though.

But I routinely all along have sent transactions of millions of coins at a time without seeing any mention of any fees.

Dust protection has to be a tiny fee on all transactions, otherwise an attacker could send medium amounts to himself many times. I don't know if the code was enforcing fees on all transactions, but that was my intent.

Oh okay, I guess I just had not noticed the fee since it wasn't actually saying anything about it (like this will cost X in fees, send anyway? or whatever).

I guess bitcoin only used coin age to prevent the sending to yourself around in circles approach to spamming/bloating the blockchain.

Not sure why we thought that wasn't enough to work for devcoin too though.

(Maybe bitcoin didn't have the coin-age parts back in those days?)

-MarkM-

Unthinkingbit

hero member

Activity: 935

Merit: 1015

Quote from: markm on December 26, 2013, 10:53:15 PM

We have always had free transactions, I think, haven't we?

Or maybe it was just taking a fee without telling me?

I have had sends to Vircurex take many hours to get confirmations, I had always figured that was because they included no fee.

Dust protection is supposed to force a few on tiny tiny transactions, not slap on a tiny fee on all transactions.

I am not positive though.

But I routinely all along have sent transactions of millions of coins at a time without seeing any mention of any fees.

Dust protection has to be a tiny fee on all transactions, otherwise an attacker could send medium amounts to himself many times. I don't know if the code was enforcing fees on all transactions, but that was my intent.

sidhujag

legendary

Activity: 2044

Merit: 1005

Quote from: markm on December 26, 2013, 10:53:15 PM

We have always had free transactions, I think, haven't we?

Or maybe it was just taking a fee without telling me?

I have had sends to Vircurex take many hours to get confirmations, I had always figured that was because they included no fee.

Dust protection is supposed to force a few on tiny tiny transactions, not slap on a tiny fee on all transactions.

I am not positive though.

But I routinely all along have sent transactions of millions of coins at a time without seeing any mention of any fees.

-MarkM-

The dust fee was always there but no box shows up it just sends it with the fee since it is small... It is now 0.2 dvc as 1 basefee is 1coin as market cap rises this makes sense.

The small transactions that are dust arent even allowed to send now..

Bittzy78

legendary

Activity: 1176

Merit: 1019

I do not give financial advice .. do your own DD

Quote from: sidhujag on December 26, 2013, 06:27:06 PM

Quote from: Bittzy78 on December 26, 2013, 05:47:21 PM

Quote from: sidhujag on December 26, 2013, 05:43:13 PM

Quote from: Bittzy78 on December 26, 2013, 05:39:53 PM

Quote from: advanced on December 26, 2013, 05:21:45 PM

i've been around for long enough to experience volatility in all its forms.

I'm totally ok with it now. I do not want total predictable reliable price stability.

I want to get a fair amount of value for open source projects funded.
The coin says that '90% of miners profits' are given away to fund those projects, right?

Maybe you can try to guarantee a minimum payout expressed in a more stable currency and then offer the payout in DVC. That would require store DVC in large quantities that could become a problem. But it is still feasible.

When and if the price stabilize then you can offer random payouts, but now... it doesn't make much sense. Not only the price of 1DVC is volatile, but even the number of coins per shares :\

I agree, the only way that someone is going to make a very expensive Devcoin ATM is if the business model of making the ATM is feasible. The 96 share bounty will simply be a bonus or a thank-you for a job well done.

My guess is there will be some company out there who makes an ATM at can accept a wide variety of crypto and Devcoin will simply be one of them.

~2 cents~

Something like a coinpayments with a logo saying wr accept coinpayments! Meaning any alts like dvc can be used to fund your account.. We should talk to coinpayments and push for people to accept coinpayments not just dvc.. and work with coinpayments to get more marketing exposure on their website so that people will start to prefer dvc as the defacto payment on their system..

That way if atm accepted coin payments it wiuld be a win win for dvc.

We have to be careful with this. We might end up with an ATM that has 6500 different logos of currency/crypto/card types that are accepted. One could spend 15 minutes trying to find the right logo to see if they can use the machine or not.

Yeah, it will probably be a company like Coinpayments and some specilized ATM maker that get together and squirt out some type of hybrid ATM that can accept cryptos. Making it might be the easy part. The hard part will be trying to convince store owners to put this machine somewhere.

Leverage the share system put them on the receiver list.. we can pay for extra exposure.. give shares to store owners for x rounds to give incentive to use ones that support devcoin.

I think that Coinpayments should probably get some shares on the receiver list as long as they accept Devcoins as payment. It could provide them some incentive to continue to do so.

There could also be an agreement to provide them a specified bounty for a website uupgrade and advertising of their services. I think the next logical step by Devcoin would be to take the bull by the horns and have partial ownership of a payment processor such as Coinpayments. I know the market cap is small right now but there could possibly be room for a 10% to 20% ownership stake if the price was right.

eeh

full member

Activity: 185

Merit: 100

Quote from: jasinlee on December 26, 2013, 11:10:09 PM

Someone delete this ^.

I reported it as spam/troll. Ridiculous.

EDIT: The Mod has deleted that enormous picture of CatCoin. Thank you, admin folks.

Topic: [DVC]DevCoin - Official Thread - Moderated - page 289. (Read 1058949 times)