Author

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

hero member
Activity: 640
Merit: 591
In the nastyfans account settings it is possible now to give a Bitcoin address to use for your identity. PGP fingerprints are also possible.
sr. member
Activity: 353
Merit: 251
I was wondering about the ASICs; I believe that in the GLBSE era there was a plan to have a certain amount of Mh/s correspond with 1 share. Now that there's been another FPGA purchase which is also another ASIC-trade-in, and now that the ASIC specs have been seriously adjusted, what does this add up to?

It may be a bit early but it does determine the value of the NastyMining Operation Smiley

See the below quote.   Smiley

Looking over the amount of BTC we've been able to mine since GLBSE went down, we have enough to order another BitForce Single SC for Nasty Mining.  This brings us to a total of 744GH/s or 29.76MH/s per seat in ASICs on order.  With there being no way to send donations to Nasty Fans currently, I feel this is a good use of BTC.

Sweet! I must have missed that. Thanks for digging up that post!
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
I was wondering about the ASICs; I believe that in the GLBSE era there was a plan to have a certain amount of Mh/s correspond with 1 share. Now that there's been another FPGA purchase which is also another ASIC-trade-in, and now that the ASIC specs have been seriously adjusted, what does this add up to?

It may be a bit early but it does determine the value of the NastyMining Operation Smiley

See the below quote.   Smiley

Looking over the amount of BTC we've been able to mine since GLBSE went down, we have enough to order another BitForce Single SC for Nasty Mining.  This brings us to a total of 744GH/s or 29.76MH/s per seat in ASICs on order.  With there being no way to send donations to Nasty Fans currently, I feel this is a good use of BTC.
sr. member
Activity: 353
Merit: 251
I was wondering about the ASICs; I believe that in the GLBSE era there was a plan to have a certain amount of Mh/s correspond with 1 share. Now that there's been another FPGA purchase which is also another ASIC-trade-in, and now that the ASIC specs have been seriously adjusted, what does this add up to?

It may be a bit early but it does determine the value of the NastyMining Operation Smiley
hero member
Activity: 634
Merit: 500
I wait to start a poll about unclaimed seats until 7 days pass with no account activation.

Right now there are 300 unclaimed seats.

I submit this poll option: Lottery - Current number of seats = number of lottery entries you get.
hero member
Activity: 640
Merit: 591
Nefario has provided me with a complete list.

E-mail was sent to the new additions. All e-mail is now sent.

nastyfans accounts are activated every day still. I wait to start a poll about unclaimed seats until 7 days pass with no account activation.

Right now there are 300 unclaimed seats.
hero member
Activity: 640
Merit: 591
Basically, assuming a default configuration, you have something like 100 "hidden" addresses sitting in your wallet.

Thank you for your efforts. I created a script to automatically extract hidden private keys using:

(pseudo-script)
listtransactions '*' | getrawtransaction 1 | dumpprivkey


I do not trust wallet.dat files. I want private keys in my backups. This script works good for me now.
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
How close are we to being able to distribute donations on nonnakip's site?

nonnakip has already completed the first donation distribution.
sr. member
Activity: 800
Merit: 250
Nefario has provided me with a complete list.  This whole GLBSE mess is nearly behind us.

Fantastic news!  Grin

How close are we to being able to distribute donations on nonnakip's site?
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
Nefario has provided me with a complete list.  This whole GLBSE mess is behind us.
sr. member
Activity: 369
Merit: 250
quotes from #bitcoin-dev on freenode IRC ( UTC-0500 / Eastern / NY time )

Code:
[17:46:08] what's the idea behind the "keypool" line of the bitcoin.conf file anyway? the comments say something about: "...so wallet backups will be valid for both prior transactions and several dozen future transactions..."
[17:46:27] I suspect... is it related to the "change" addreses or something?
[17:49:10] kuzetsa: not just change, though that too.
[17:49:29] e.g. you make a backup. then 10 seconds later you get a new address from bitcoin so someone can pay you.
[17:49:38] It would be nice if that didn't invalidate your backup.
[17:49:44] And it doesn't— because of the keypool.
[17:51:16] right
[17:51:24] * Matt_von_Mises ([email protected]) Quit (Quit: Leaving.)
[17:52:34] It just precomputes the next N addresses that it will use, so they end up in the backup and if you repeat backups at least every N addresses that you consume your backups will be good.
[17:53:02] yeah
[17:55:49] mind if I quote you on that?
[17:56:15] I mean, it sounds factual / common sense, but I like your explaination better than I would've worded it.
[17:56:39] fine with me

^Basically, assuming a default configuration, you have something like 100 "hidden" addresses sitting in your wallet.

These public / private keypairs aren't just used for change, but are also the pre-generated ones which will be used for the next time you were to click [+new address] on the receive coins tab (assuming bitcoin qt, the gui version of the satoshi client... I realize in your case it's bitcoind, but either way it uses the same conf file format and settings and same basic code for all bitcoin transactions and such)
sr. member
Activity: 369
Merit: 250
It's explained here: Change (bitcoin wiki)

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

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.

Not sure if this is related to change addresses, but it's a WEIRD section of an older bitcoin.conf file referring to public / private keypairs
(a default one / from long before I modified everything to my needs. Been several versions back since I had a fresh install)

Code:

 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 #keypool=100

hero member
Activity: 640
Merit: 591
It's explained here: Change (bitcoin wiki)

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

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.
sr. member
Activity: 369
Merit: 250
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

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.

You probably just forgot to specify which address to return the change to (didn't send the whole amount) For example: if you have exactly 25 bitcoin in an address you control, and then spend 2 bitcoin: Transaction is created which sends 2 bitcoin, as well as the leftover 23 bitcoin to a random "change" address which you control (it's in your wallet)

It's explained here: Change (bitcoin wiki)

... I suspected it might've been a change address. Thanks for confirming.
hero member
Activity: 640
Merit: 591
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

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.
sr. member
Activity: 369
Merit: 250
I think we'll be moving away from weekly donation distributions soon in favor of real time distributions.

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?

Quoted for emphasis / Agreed!!!





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 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.
DISCLAIMER: I didn't actually do any maths on this.

Wouldn't that eat much more transactions fees?

Simply put, yes... Sending such small amounts is difficult, and spending them is even harder:

Transaction fees (bitcoin wiki)

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.



... and a public IRC realtime chat discussion on the subject of transactions / mining / fees / filtering / etc.

Quote
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: Smiley
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
member
Activity: 73
Merit: 10
I think we'll be moving away from weekly donation distributions soon in favor of real time distributions.

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?
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
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 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.
DISCLAIMER: I didn't actually do any maths on this.

Wouldn't that eat much more transactions fees?

nonnakip has gone through a great deal of effort behind the scenes to minimize these fees.
hero member
Activity: 560
Merit: 500
I am the one who knocks
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 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.
DISCLAIMER: I didn't actually do any maths on this.

Wouldn't that eat much more transactions fees?
sr. member
Activity: 369
Merit: 250
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.

Speaking of math:

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
Jump to: