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

Nefario has provided me with a complete list.  This whole GLBSE mess is nearly behind us.

Thank you for this information. bitcoind does not list the address as a receiveaddress. But I can dump the private key. I do not like that the address is hidden in bitcoind. I will search how to manage hidden private keys with bitcoind.

It's explained here: Change (bitcoin wiki)

... I suspected it might've been a change address. Thanks for confirming.

This is something I do not yet understand about Bitcoin. The 0.13182934 BTC did not come from me and was not taken from my account. Also that address was not in my recipient list.

I believe Bitcoin does some rearrangement when creating the block. I notice this with other transactions. Maybe somebody here can explain or give a link where these details are explained.

With the exception of a single address, all of the sent BTC went out in multiples of exactly 0.00131686 BTC per seat. The amount sent to the one address which wasn't an exact multiple received 100x 0.00131686 BTC "seats" plus another 0.00014334 BTC (for a total of 0.13182934 BTC)

Kinda wonder why this one was a special case: 1NZjSBtHN78HX9329t3epfyyu6NgUqQap3

Personally, I would prefer a daily or weekly distribution to a real time one. Many small transactions don't do the blockchain any good and I don't see any benefits for the club members to doing it real time. Perhaps we can start a poll for this?

DISCLAIMER: I didn't actually do any maths on this.

Wouldn't that eat much more transactions fees?

FWIW, all pools have been experiencing higher stales and orphaned blocks due to the excessive transaction volume lately resulting from SatoshiDice abusing the blockchain (there are much cleaner ways to do the same thing). After our second set of 3 orphans in a row, I'm a bit on the annoyed end. For now, I am blocking transactions to 1dice* addresses and limiting our blocks to 32 transactions until we've caught up on the extra credit or at least have a viable alternative solution. I really hate to do this, as Eligius has traditionally been one of the most accepting mining pools, so any suggestions on other possibilities would be most welcome.

While SatoshiDice does force its users/victims to pay a transaction fee, those fees despite their high volume still don't add up to anywhere near the 300+ BTC we've lost by mining their transactions - so it's not like we can just "make up for" the orphans by throwing transaction fees into the pot.

Note that this is really a global Bitcoin scalability problem, but wasn't an immediate issue because up until recently the transaction volume growth was accompanied by an equivalent influx of more people using Bitcoin. SatoshiDice's abuse breaks that balance, so the developer and mining communities need to find a solution faster than previously anticipated.

29.10.12 14:05:20 Smoovious: the whole point of mining is processing transactions... so if you're not doing that? you don't get rewarded for it
29.10.12 14:05:53 kfrog: I would mine all day long just for transaction fees
29.10.12 14:05:59 kfrog:
29.10.12 14:06:15 laSeek: Do some pools create new blocks without transactions - or do they skim off the transaction value for themselves and pay miners only for the raw block?
29.10.12 14:06:23 kfrog: whats up guys
29.10.12 14:06:31 laSeek: Wotcha kf
29.10.12 14:06:40 Smoovious: yeah... the reward is supposed to just be a subsidy... it isn't supposed to be the whole point of it
29.10.12 14:06:55 laSeek: aye
29.10.12 14:07:26 Smoovious: laSeek: some pools don't include transactions... individuals too... others, filter out transactions (like satoshi dice ones), for whatever reason
29.10.12 14:08:00 laSeek: Although I was thinking of transactions the other day - in theory you could push transactions to an alt block off minted blocks
29.10.12 14:08:01 Smoovious: I'm cool with picking and choosing transactions based on the fee and stuff... as long as they are including transactions to begin with
29.10.12 14:08:28 Smoovious: but to just go 'fuck transactions' and not process them at all? that's messed up
29.10.12 14:08:44 kfrog: +1
29.10.12 14:08:51 laSeek: Which would mean you could have a transaction block with only the value of transactions
29.10.12 14:09:35 Smoovious: I had this argument with luke-jr and a couple other guys about satoshi dice's transactions... far as I'm concerned, if they are including the proper fee, how are they an 'attack'? just process the transactions
29.10.12 14:09:49 laSeek: if you rate the diff of the alt chain based on the mined main block (something like 1/4) - you could have transaction processing nodes
29.10.12 14:10:43 laSeek: Some of the devs are worried about block size I think - their worry is about the script attached to blocks for the trans
29.10.12 14:10:45 Smoovious: if you're mining, you're a transaction processing node... far as I'm concerned
29.10.12 14:10:57 efx: agreed
29.10.12 14:11:56 Smoovious: well, they can either do something to accomodate the amount of transactions now, or later... but if the network grows like they keep saying they want it to? I don't know they expect that to happen without lots of transactions increasing the block size
29.10.12 14:12:00 laSeek: aye Smoov - you are currently. The problem I have is that the transaction conf time currently is based off the block creation time
29.10.12 14:12:46 Smoovious: satoshi dice is doing them a favor with a real-world scenario, early enough to work on something usable, at a time where it is still early enough
29.10.12 14:12:53 laSeek: aye - there's been some talk about how to manage transactions - although most of the current focus is based around some kind of pruning to manage the startup time of the daemon
29.10.12 14:12:59 laSeek: aye
29.10.12 14:13:18 Smoovious: if ya put it off to deal with until later, ya could end up handling it badly and rushed, and drive people away
29.10.12 14:13:51 laSeek: Luke isn't the person for this type of discussion - Gavin is probably a better sounding board
29.10.12 14:14:21 Smoovious: well, I forget who else was involved in the discussion... (less of a discussion, more of a fight, really)
29.10.12 14:14:48 laSeek: heh - devs aren't always easy to have a blue sky discussion with

I think we'll be moving away from weekly donation distributions soon in favor of real time distributions.

DISCLAIMER: I didn't actually do any maths on this.

Wouldn't that eat much more transactions fees?

I think we'll be moving away from weekly donation distributions soon in favor of real time distributions. That being said, NASTY MINING is currently mining around 1BTC per day with the FPGA setup. It will be a much different story when ASICs arrive.

The donation page is not yet automatic. I updated it to show the last distribution. I know that it must be better and it will be. I wanted the important details up as fast as possible. I am sure others will be verifying the math.

Question; is this dividend a fair representation of the coming weekly dividends? Or was there much time lost reconfiguring different pools and the new version of CGMiner?

I know things are getting a little tense here, but can we give OgNasty and nonnakip a little slack while things get put in place?  
...

Could you provide your investors with the details on NASTY mining operation? For example how much have you mined since GLBSE shutdown, how much have you spent on additional mining hardware and etc.

I do not notice any effect of unconfirmed coins to mining payout, because I do not know about any failure of your mining operation (you did not start mining first coins this week, you continued to mine all the time since GLBSE shutdown, so last week unconfirmed coins, adds to next week payout, hence weekly payout should not be effected by unconfirmed rewards, payout depends on mining capacity, bitcoin network difficulty and pool luck if any.


Would you care to explain how to include "set up mining operation in preparation for the arrival of ASIC hardware"?