Topic: 📈 NastyFans: The Bitcoin Enthusiast Fan Club (est. 2012) - page 172. (Read 958997 times)

not really sure why this matters?

i do not have many shares so it is not really high priority. just something i want to get done since i am owed for this

sent an email as a reply to a message i received. so i was expecting it to make it somewhere it would get a response

Why did you wait so long to post here?  Did you attempt to PM him on this forum?

on january 8th i replied to a message i received from [email protected] requesting help

have not gotten anything back


I have not gotten any payments and am expecting this to be resolved and all back payments made up to this point to others to be made to my address

Exactly, thanks indeed!

I am happy with those interpretations.

I also want to clarify the last point... I never thought you were greedy.  I just wanted to make sure that we considered all the sides, thank you for not letting ego get in the way as some may have.

The current nastyfans policy is missing clarifications:

• payment received: In the Bitcoin world this is not a clear statement. A payment has multiple parts: transaction submission and inclusion in the block chain and multiple confirmations in the block chain.
• unexpected payments: If unexpected Bitcoins appear at a address controlled by nastyfans it is not specified what happens to those Bitcoins.

Both of these situations occur since nastyfans begins. The missing clarifications were implemented using my own interpretation of policy. For "payment received" I interpreted this as 6 confirmations. For "unexpected payments" I interpreted this as donations to nastyfans.

ErebusBat makes a very good argument that payments may be late in the blockchain and it is not the fault of the member. Akka provides a very good suggestion to prevent this problem. "payment received" is now interpreted as transaction submitted. nastyfans still requires 6 confirmations to transfer seat ownership. But now there is no risk for buyers that their client or miners cause problems for the buy.

For "unexpected payments" there are already 3 incidents where overpayments happen. These became donations and were included in distributions 212573 and 217037. kuzetsa makes a very good argument about nastyfans not taking unexpected payments as a donation. Indeed it does not fit the "spirit" of nastyfans.

Now all unexpected payments will be carefully handled to return the Bitcoins to the owner. If it is not clear who the owner is or if the owner does not have a donation address I will use social methods to discover the owner. nastyfans will now only accept donations to the official donation address.

The 3 overpayment issues total 0.006 BTC. I now sent this amount to the nastyfans donation address from my personal wallet. But this will not be included in the next distribution. Instead it will be sent to the 3 members that overpaid. This is fair for the other members because they already received the 0.006 BTC in distributions 212573 and 217037.

Now nastyfans acts in the correct "spirit". Members do not need to worry about accidental payments or overpayments or underpayments. Any payment mistakes are detected and will be returned in full. Members do not need to worry about confirmations for payments. Only the payment submission must happen within 6 blocks of clicking "buy".

I will create a poll to add these details to the policy. Right now they are in effect as "interpretations" of the "spirit" of the policy. But I want them to be clearly stated so my actions are clearly reinforced.

I apologize for my greedy interpretations of the policy. Thank you Akka and Newar and ErebusBat and kuzetsa for your efforts to keep nastyfans clean. I am happy to have such members in our club.

I think that these, or something resembling/inspired by them are the only sane way to go.  I wouldn't worry about the micro-donations, but as you said if 1000BTC lands in our laps then we should know (in general) our plan of action.

Nope.

It's not in the policy / completely unable to figure out why you think it is clear.





^Which line(s) of this are "clear" and back up your statement of "It should be a donation"

I waited a few days before bringing this up again, and haven't seen any explanation, nor has a poll been put up on the matter.

It is wrong to assume a user has access to a sender address. I do not care if some services work that way. It is a false assumption and will cause problems in the future.


I do not understand how that is better. Let us use the example that started this conversation:

https://blockchain.info/tx/dfb30e8dd29628b3ee14ff6b0b2d9946845a919b240cefffc2ebeab6327e92b4

In this case one of the addresses is actually a donation address. But what if that was not the case? Which address do I send the refund to?? Any of them?


I agree completely and want to be fair. That is why we are discussing this. But I do not want to send Bitcoins to some address that may not be accessible for the user. That is bad policy.

Perhaps it is easier to create a "lost and found" on nastyfans. It applies to each member individually. Then members have time to decide what should be done and where to send the refund. For each lost item a text area can be available for the member to enter instructions.

This does not clarify anonymous Bitcoin deposits. If suddenly 1000 BTC land in a nastyfans address I still do not know what to do. Maybe a general "lost and found" where we can use a poll to decide what to do.

I would say that is a pretty bold statement.  Also not all online services work that way, BlockChain.info's MyWallet for example works exactly like a desktop wallet, while InstaWallet functions as you say.

I would still say it is a better policy than just taking the coins and saying 'oh well... thanks for the donation'.   Several sites/services that REQUIRE the user to be in control of the sending address exist and have been very clear and don't seem to have an image problem.

I guess we could have a new option in settings:
[ ] If my TX has a bunch of dust inputs, so it is unlikley to get confirmed in a timley manner, then just treat seat purchases as a donation.  (If this option is unchecked and TXs are not 6xConfirmed in 144 blocks after your TX then it will be sent back once the TX eventually confirms (miuns 0.0005 fee).

But I don't really like that option either.  I think a simple warning on a purchase is much more sane:
WARNING: If your TX is not 6xConfirmed by block # xxxxxx (approx XYZ hours from now), then once it does finally confirm it will be sent back to you minus 0.0005 TX fee.  This is to ensure that seats are not locked forever.


One reason I am so adamant about this is because it is very possible for this to happen completely out of the users hands with many small inputs.  If their client doesn't do the right thing, or even if it does some mining pools will deliberately prioritize large TXs with small amounts.  Also a message about using the correct fees might be good.

/rant off

No. This is on the list of features to implement. I have all the data. When the feature exists you will see all past buy transactions when you bought and all past payment transactions to you when you sold.

Is there a way to see a transaction history for seats I bought / sold on the site?

Instead of claiming bugs maybe you explain how it should be handled.

Situation: A member buys a set with a transaction with 100000 microcoins and 0 tx fee. nastyfans sees the transaction and locks the seat. And now? If no miner ever includes that transaction in a block? We lock the seat forever?

Until now the answer was "no". After 7 blocks the purchase order is canceled. After suggestion from Akka it is now "yes". The seat is locked forever until the transaction is accepted.

The policy talks about "payment received" within 7 blocks. Until now I interpreted that as "part of the block chain". Now I interpret it as "transaction submitted". But then we must define a limit to the transaction inclusion in the block chain. Or we define that there is no limit. Right now there is no limit.


It is not a bug. Policy was clear in this case. It should be a donation. I manually violated policy because I think policy maybe unfair here. I now implement a new policy interpretation and ask for policy language clarification so there is no more room for interpretation.


This was a problem because I did not understand complexity of micro coins. Thank you for your help with that issue. I am now very comfortable with micro coins.


Distribution 213576 had the large delay because of micro coin problems. All other distributions have a delay of maybe 10 seconds. For a distribution the current seat numbers are checked then the bitcoind command is generated then the command is executed. Since micro coin problems are solved the generated command is executed without problems and with only 0.0005 BTC tx fee.

The system is automated and works very well. If issues like yesterday happen I see warnings so I can manually investigate. The system did not have a problem. I noticed that policy was unfair.

You can not assume that people have access to receive Bitcoin from the sender address. Most people use online services and the sender address belongs to the service not the user.

I would love to send it back. But Bitcoin does not work like that. If there is no donation address then there is no guarantee that the Bitcoin is sent to sender.

@nonnakip: WHAT!? The NastyFans policy says nothing along the lines:

...If an auction transaction takes too long for whatever arbitrary reason(s), we will just claim your bitcoin as a "donation".


@ErebusBat: Yes. I agree.

... Though your "in the future" qualifier is not even the case:

This CURRENTLY looks very bad for nastyfans/nastymining, as it is a
systemic design flaw which is not supported by the NastyFans.org policy.
(neither the exact wording, nor the "spirit", nor intended... so basically it's a bug.)

---

Edited to add:

I'm really glad that things are working as well as they are. Thanks for all the hard work nonnakip, I'm really glad this is only the second major bug I've noticed. The first one I noticed personally, as it affected the distribution of donations after I had picked up a few new seats.


... I think something related to the distribution being sent out manually or something? Is this still the way it's done or is there a new system? When someone picks up new seats & the ownership is transferred to the new fan/owner, like basically...

err... I guess my question is: How much delay is there? Is there a new practice or procedure for calculating "seats per fan" when distributing donations so that things get re-calculated to be "up to the minute" accurate to make sure everyone gets the right amount?

Why the need for the donation distinction? Why not just send back to the sending address?  I think taking funds like that could make nasty fans look very bad in the future.

This is not about long block times. The issue today was because the transaction was sent but it was not picked up by a miner until 13 blocks later. Maybe the tx fee was too small?

This is about how long we wait for transactions to be picked up. If the tx fee is too small maybe it is never picked up. But we do not want to lock seats forever. We need some time limit. If it is picked up after the limit then it becomes a donation to nastyfans or refunded to buyer minus 0.0005 BTC.

After sitting on my brain for a day I recommend:

1. The buyer must submit a transaction within 7 blocks. (This clarifies existing policy.)
2. The transaction must become part of the main chain within 1000 blocks. (This is new policy.)
3. The transaction is valid after 6 confirmations. (This is already policy.)
4. If a transaction is submitted within 7 blocks but does not become part of the main chain within 1000 blocks the purchase order is canceled. If the transaction becomes part of the main chain after the purchase order cancellation then nastyfans will refund the amount (minus 0.0005 BTC tx fee) to the buyer if the buyer accepts donations. Otherwise it becomes a nastyfans donation. (This is new policy.)

If there are no good objections I will start a poll for these policy additions.

How about: 6 x 1 h 39 min ~= 12 hours?

Lord I hope not.