Bitcoin Forum
December 10, 2024, 06:32:00 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 416 »
  Print  
Author Topic: [ANN] Litecoin - a lite version of Bitcoin. Launched!  (Read 1467326 times)
CAMOPEJB
Full Member
***
Offline Offline

Activity: 132
Merit: 100



View Profile
November 21, 2011, 11:12:57 AM
 #1221

Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore.

I think it's a great idea to pay fee if you are sending coins to more than one address at the same time - common user will never use that option and it will stop spamers!

You have my support on it.  Smiley
localhost
Sr. Member
****
Offline Offline

Activity: 392
Merit: 250


View Profile
November 21, 2011, 11:15:03 AM
 #1222

I like this idea too Smiley

-
bulanula
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
November 21, 2011, 11:25:28 AM
 #1223

Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS Shocked. Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself.
Schwede65
Sr. Member
****
Offline Offline

Activity: 309
Merit: 250


View Profile
November 21, 2011, 11:41:14 AM
 #1224

Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS Shocked. Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself.

for whom is it useful to send one amount to many addresses at once?

i give u a little hint: spammers...

Great idea of coblee  Smiley

the fee for an output greater then 2 = 0.1 LTC/each transaction

in my opinion it should be higher for greater outputs:
for an output greater then 10 = 1 LTC/each transaction
CAMOPEJB
Full Member
***
Offline Offline

Activity: 132
Merit: 100



View Profile
November 21, 2011, 11:42:51 AM
 #1225

ha-blody-ha!

bulanula, do you have any better solution to spam or even just idea?
coblee (OP)
Donator
Legendary
*
Offline Offline

Activity: 1654
Merit: 1354


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
November 21, 2011, 12:18:49 PM
 #1226

I don't really understand the inner workings of those transactions (and I'm just discovering about relay fees), but I guess if there was a way to make the transaction fee work per receiving address (like, sending 0.000001 LTC 100 times to different addresses or even from the same address to the same address = paying 100*0.1=10 LTC in transaction fees) this would impair his ability to cheaply make large transactions while not being an issue for legitimate users.

Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore.

This might not be the best idea. Might work in the short term, but in the long term we probably don't want to do that. The main reason to use sendmany is to limit chain growth, so seems kind of silly to punish use of it. The idea I was going with is to punish someone for sending dust spam. Here's the original code:

        // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
        if (nMinFee < nBaseFee)
            BOOST_FOREACH(const CTxOut& txout, vout)
                if (txout.nValue < CENT)
                    nMinFee = nBaseFee;

Basically, we were setting min fee to at least 0.1 LTC if any of your output is less than 0.01 LTC. I'd like to extend that to add 0.1 LTC for every output less than 0.01 LTC. So using sendmany to send to 1000 outputs is fine as long as you are paying the 0.1 LTC fee per 1000 bytes. But if you are sending 0.00000001 LTC to each of those 1000 outputs, then you need to pay an additional 100 LTC in fees.

        // To limit dust spam, add MIN_TX_FEE/MIN_RELAY_TX_FEE for any output is less than 0.01
        BOOST_FOREACH(const CTxOut& txout, vout)
            if (txout.nValue < CENT)
                nMinFee += nBaseFee;

The spammer can still send a ton of 0.01 outputs, but this will deal with the dust spam. It's really hard for the receiving end to collect these worthless transactions.

kano
Legendary
*
Offline Offline

Activity: 4634
Merit: 1851


Linux since 1997 RedHat 4


View Profile
November 21, 2011, 12:27:01 PM
 #1227

Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS Shocked. Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself.

for whom is it useful to send one amount to many addresses at once?

i give u a little hint: spammers...

Great idea of coblee  Smiley

the fee for an output greater then 2 = 0.1 LTC/each transaction

in my opinion it should be higher for greater outputs:
for an output greater then 10 = 1 LTC/each transaction


Sigh ... knee-jerk reactions don't solve problems (as we have already seen ...)

Although no one already does, you would hope that people (e.g. pools) would actually make single transaction payments rather than multiple 2 output transactions.

This change is just saying that people should only use a standard 2 output txn for everything they do and not promoting optimum use of transactions at all.

Since your both just picking random numbers and not thinking about them or asking for input on them, then pick 2 much larger random numbers.

It would be WAY worse if the person doing this decided to put every single output pair into it's own transaction ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
FlipPro
Legendary
*
Offline Offline

Activity: 1764
Merit: 1015


View Profile
November 21, 2011, 12:33:15 PM
 #1228

Not good idea. Send many is very useful and needed. You are sounding more and more like RealScam with these demonic measures and frequent client updates ( remember SC beta 5 then 6 then 7 all in like 1 hour ? ). Let the miners decide if the chain is bloated and the TX fees. Maybe coblee is RS Shocked. Kind of makes sense : you control the biggest competitor to SC and get all the market for altcoins by yourself.
LOL  Cheesy Cheesy Now Litecoin finds itself in the same predicament that Solidcoin had to solve to fend off malicious attackers. It's going to be very interesting seeing how Coblee fixes this "bug" in the protocol.
coblee (OP)
Donator
Legendary
*
Offline Offline

Activity: 1654
Merit: 1354


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
November 21, 2011, 12:36:22 PM
 #1229

It would be WAY worse if the person doing this decided to put every single output pair into it's own transaction ...

If he sent 1 transaction for each of his 0.00000001 LTC output, he would have needed to pay 0.1 LTC for EACH transaction. Or at least 0.02 LTC per transaction with the relay transaction workaround. I don't see how that's way worse. He's taking advantage of the fact that the fee system charges less fee for dust spams using sendmany. Please see my previous post on how I want to fix that.

coblee (OP)
Donator
Legendary
*
Offline Offline

Activity: 1654
Merit: 1354


Creator of Litecoin. Cryptocurrency enthusiast.


View Profile
November 21, 2011, 12:39:41 PM
 #1230

I don't really understand the inner workings of those transactions (and I'm just discovering about relay fees), but I guess if there was a way to make the transaction fee work per receiving address (like, sending 0.000001 LTC 100 times to different addresses or even from the same address to the same address = paying 100*0.1=10 LTC in transaction fees) this would impair his ability to cheaply make large transactions while not being an issue for legitimate users.

Here's my latest thought. I can force a transaction fee for each output greater than 2. Normal users will only send transactions to 1 address with a address for the change. Only advanced users will use the sendmany api to send coins to many address at once. I can force a fee to use the sendmany feature. So for every output greater than 2, you have to pay an additional 0.1 LTC fee. Without the ability to send to multiple addresses at once, I don't think the spammer can bloat the chain cheaply anymore.

This might not be the best idea. Might work in the short term, but in the long term we probably don't want to do that. The main reason to use sendmany is to limit chain growth, so seems kind of silly to punish use of it. The idea I was going with is to punish someone for sending dust spam. Here's the original code:

        // To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
        if (nMinFee < nBaseFee)
            BOOST_FOREACH(const CTxOut& txout, vout)
                if (txout.nValue < CENT)
                    nMinFee = nBaseFee;

Basically, we were setting min fee to at least 0.1 LTC if any of your output is less than 0.01 LTC. I'd like to extend that to add 0.1 LTC for every output less than 0.01 LTC. So using sendmany to send to 1000 outputs is fine as long as you are paying the 0.1 LTC fee per 1000 bytes. But if you are sending 0.00000001 LTC to each of those 1000 outputs, then you need to pay an additional 100 LTC in fees.

        // To limit dust spam, add MIN_TX_FEE/MIN_RELAY_TX_FEE for any output is less than 0.01
        BOOST_FOREACH(const CTxOut& txout, vout)
            if (txout.nValue < CENT)
                nMinFee += nBaseFee;

The spammer can still send a ton of 0.01 outputs, but this will deal with the dust spam. It's really hard for the receiving end to collect these worthless transactions.

Here's this code in action on the testnet: http://blockexplorer.sytes.net/block/d1d987e3674b5f17a7881220376fb97aad9ec31880ac87b225c8dad5801dd215
Each output that is less than a litecent adds an additional 0.1 LTC fee.

tacotime
Legendary
*
Offline Offline

Activity: 1484
Merit: 1005



View Profile
November 21, 2011, 01:29:30 PM
 #1231

holy shit, just woke up to a 300% increase in difficulty.. The price of ltc may rally today.

Code:
XMR: 44GBHzv6ZyQdJkjqZje6KLZ3xSyN1hBSFAnLP6EAqJtCRVzMzZmeXTC2AHKDS9aEDTRKmo6a6o9r9j86pYfhCWDkKjbtcns
btc_artist
Full Member
***
Offline Offline

Activity: 154
Merit: 102

Bitcoin!


View Profile WWW
November 21, 2011, 03:07:00 PM
 #1232

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?
It's a cat and mouse game.  Would not the spammer just use coins that are two days old in that case?

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1002


View Profile
November 21, 2011, 03:30:03 PM
 #1233

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?
It's a cat and mouse game.  Would not the spammer just use coins that are two days old in that case?

He would have to wait 2 days to be able to spam again after he exhausted his funds.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
btc_artist
Full Member
***
Offline Offline

Activity: 154
Merit: 102

Bitcoin!


View Profile WWW
November 21, 2011, 03:31:53 PM
 #1234

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?
It's a cat and mouse game.  Would not the spammer just use coins that are two days old in that case?

He would have to wait 2 days to be able to spam again after he exhausted his funds.
We don't know how many coins he has.  He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1002


View Profile
November 21, 2011, 03:38:31 PM
 #1235

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?
It's a cat and mouse game.  Would not the spammer just use coins that are two days old in that case?

He would have to wait 2 days to be able to spam again after he exhausted his funds.
We don't know how many coins he has.  He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know.

Meh.  Bitcoin has solved the problem with a combination of time and value based fee requirements.  Why reinvent the wheel here?

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
btc_artist
Full Member
***
Offline Offline

Activity: 154
Merit: 102

Bitcoin!


View Profile WWW
November 21, 2011, 03:40:44 PM
 #1236

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?
It's a cat and mouse game.  Would not the spammer just use coins that are two days old in that case?

He would have to wait 2 days to be able to spam again after he exhausted his funds.
We don't know how many coins he has.  He could spam for two days using 5% of his coins, and then start recycling the spammed ones for all we know.

Meh.  Bitcoin has solved the problem with a combination of time and value based fee requirements.  Why reinvent the wheel here?
Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
btc_artist
Full Member
***
Offline Offline

Activity: 154
Merit: 102

Bitcoin!


View Profile WWW
November 21, 2011, 03:46:23 PM
 #1237

Though there is one solution I can think of. Which is to require a transaction fee on all coins sent that are not a day old. So if you try to send coins that are not a day old (i.e. don't have 576 confirmations), you need to pay 0.1 ltc fee. What do people think about that?

That would probably be ok, however, you can't choose which coins to use so if you had a bunch of older coins and one new one which was exactly the size you want, I think the client would choose that one.  We'd need to combine it with a tweak to the coin selection algorithm.
If he's using custom code to create the transactions, he can use whichever coins he wants to.

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
notme
Legendary
*
Offline Offline

Activity: 1904
Merit: 1002


View Profile
November 21, 2011, 04:05:29 PM
 #1238

Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.

Then why are we wasting time talking about how to fix it?  Maybe I jumped in the middle of something without realizing what was really being discussed.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
FlipPro
Legendary
*
Offline Offline

Activity: 1764
Merit: 1015


View Profile
November 21, 2011, 04:07:59 PM
 #1239

Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.

Then why are we wasting time talking about how to fix it?  Maybe I jumped in the middle of something without realizing what was really being discussed.
HENCE THE ENTIRE DILEMMA  Cheesy Cheesy Cheesy.

btc_artist
Full Member
***
Offline Offline

Activity: 154
Merit: 102

Bitcoin!


View Profile WWW
November 21, 2011, 04:11:08 PM
 #1240

Litecoin is using the exact same solution as Bitcoin, AFAIK, the only difference being the coin values have been increased to match real-world values.

Then why are we wasting time talking about how to fix it?  Maybe I jumped in the middle of something without realizing what was really being discussed.
Alternate solutions are being discussed, but the currently implemented solution is what I said. (unless I'm mistaken)

BTC: 1CDCLDBHbAzHyYUkk1wYHPYmrtDZNhk8zf
LTC: LMS7SqZJnqzxo76iDSEua33WCyYZdjaQoE
Pages: « 1 ... 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 [62] 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 ... 416 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!