i just updated goxtool and the "bars" went ugly, is this on purpose?
|
|
|
K4T13 ----->100 SXC kelsey ----->100 SXC emunebtk --->50 SXC K1773R ----->50 Collectible SXC de_xt ------>100 SXC zenrog ----->50 SXC noelmal----->100 SXC tadakaluri-->50 SXC iluvpcs ---->50 SXC thanks
|
|
|
Good idea Richy! Suggestion: send the coins to a new temporary Address, wait for 6 confirmations, now create a tx for an address you want the coins go to and save it (or create QR code, saving is better). Why? Since the "actual location" of the coins would be a temporary address which is imported nowhere, not even having the users wallet.dat would help. if someone would have the privkeys he could still steal your BTC as your TX would be a double spend (thats why the thing with the temporary address). Nobody knows the privkey of the temporary address so the bitcoins are "lost" until you publish your signed raw TX how about this? Yes, I think that's basically it. Your bitcoins would be stored in a wallet that had no form of existence (other than for the short time it took to receive the coins and generate the transaction). thats a really good idea, gonna do this in the future for sure
|
|
|
I'm hungry... who has a few bbq coins for me? bJcXcZ7MQRMeZzf92iSRxJiAzxqqCfmiic Thank you in advance! 1BQC on your way
|
|
|
Good idea Richy! Suggestion: send the coins to a new temporary Address, wait for 6 confirmations, now create a tx for an address you want the coins go to and save it (or create QR code, saving is better). Why? Since the "actual location" of the coins would be a temporary address which is imported nowhere, not even having the users wallet.dat would help. if someone would have the privkeys he could still steal your BTC as your TX would be a double spend (thats why the thing with the temporary address). Nobody knows the privkey of the temporary address so the bitcoins are "lost" until you publish your signed raw TX how about this?
|
|
|
Very interested, merge mine with LTC will be revolutionary
Thank you - this is the technical hurdle we are still overcoming and we are looking for an LTC mining pool where we can test our LTC merge mining. I'll be honest - we really need to test this LTC merge mining in the wild before launching ETC. So if you know a large LTC mining pool willing to support our tests please let me know p2pool would be the easiest way.
|
|
|
SK1773RspSAtaF1esY7dJrSmaQxRzyvFKH
|
|
|
since im a collector i cant miss that SK1773RspSAtaF1esY7dJrSmaQxRzyvFKH (just had to use vanitiygen)
|
|
|
so many software guys fundamentally do not understand hardware
maybe if it cost you a few thousand dollars every time you invoked gcc
well, thats the fault of the nowadays used programming languages which are all almost likely do_magic(). also winblows/osx hurts you alot if your a developer
|
|
|
are you unable to read? Warning! this transaction is a double spend of 75609966. You should be extremely careful when trusting any transactions to/from this sender.
|
|
|
FFS, this is the "Armory - Discussion Thread" not the "Ripple sucks Thread". There are enough threads about Ripple so pls keep the ripple chat/talk out of here... ty!
|
|
|
Seriously, the support asking for here is: "How do I access a file on windows" Can we avoid "how do I use a computer" posts for page after page thanks? Waste of damn space.
seems we need a "how to commit suicide to increase the overall inteligence of humanity"
|
|
|
I don't know the exact reason why getblocktemplate affected efficiency and even if it's still the case today as forrestv might have changed something that removes this problem. It was still the case very recently (like less than 2 months ago) when getblocktemplate took more than 0.2s. I don't check often how it affects p2pool but I'm doing it right now (in fact I'm studying how the block size and fee limits affect getblocktemplate in the current situation, checking the efficiency is just a bonus). If the behavior of p2pool changed I'll know it in the following days and will be able to update my guide. For now I still recommend to keep it under 0.2s to be safe.
Some recent findings on P2Pool efficiency on my node. My node is directly connected to the Internet with Ethernet, 100 Mbit/s downstream and 10 Mbit/s upstream. The node is a Phenom four-core processor, with SSD disk. I have 7 mining rigs connected to the node via LAN. All numbers below are with current (April 2013) P2Pool from Github. When my configuration was incorrect and Bitcoind could only make outgoing connections, my efficiency was between 95% and 99%. After fixing the configuration problem, efficiency rose to 110-115% level. I have now 30-40 connections to the Bitcoin network. When the getblocktemplate latency started to appear, my efficiency was still between 110-115%. My getblocktemplate latency was about 30 seconds at that time. I have now upgraded to the 0.8.2rc3 version, and the getblocktemplate latency decreased to about 0.1 seconds, but it has increased to 0.9 seconds since the upgrade (in four hours). Current efficiency after two hours from the upgrade is 102.4%. Well, I think one cannot deduce anything from that yet, maybe the stopping and restarting of bitcoind caused some orphans. I'll report the efficiency back to this thread after 24 hours have passed with this new bitcoind version. So, now the pool has run for over 24 hours with the new bitcoind version and: # default is 500000, 1000000 is the maximum allowed and will fit more transactions (more fees) blockmaxsize=1000000 #Fee-per-kilobyte amount (in BTC) considered the same as "free" #Be careful setting this: if you set it to zero then #a transaction spammer can cheaply fill blocks using #1-satoshi-fee transactions. It should be set above the real #cost to you of processing a transaction. mintxfee=0.00001 # Same but for relaying the tx to our peers minrelaytxfee=0.00001
settings. I have found 70 shares now, 7 orphan and 5 dead, for stale rate of 17.1% (10-28% interval). Pool stale rate is 20.4% now, so efficiency is 104% (90-113% interval). One thing I remembered was that I have downclocked my CPU to 1.2 GHz from the default clock rate of 2.5 GHz or so to save a little CPU. That might affect things a bit. I might check that at some point. bitcoind getblocklatency is 0.93 seconds now, so it is much better than the 30 seconds earlier. I think the CPU frequency affects this latency the most, and was likely the reason my latency was 30s with the old bitcoind version. no need to downclock, thats sutpid!
|
|
|
I have a question, is the entropy source in Vanitygen reliable enough to use it as a simple Bitcoin address generator? Like just specify the pattern "1", the combination it then outputs, is it secure and not vulnerable?
its based on OpenSSL's, so yes it should be fine.
|
|
|
It's done, please try
To make it faster I don't catch exceptions so if you provide at least one transaction that isn't in your wallet it will crash without telling you which one Maybe you prefer catching exceptions and avoiding all the deletions to be canceled just because one failed, just tell me what is better
I added the exit code 1 in case of failure
To everybody Do you think pywallet would be more practical as a Qt app? As I said earlier I'm wondering about recoding everything. It's far from sure but if I decide to I'd like to know how to make it more user-friendly.
full CLI (ie the same capabilites like the WUI) and a WUI should be doing fine.
|
|
|
funny the OP edited his post but forgot that others quoted his original text, morons lol...
|
|
|
Thanks.
How to apply it to my p2pool? I have only p2pool from git and stratum-mining-proxy from git.
save the text above in a file and use patch(1)basic linux stuff u should know
|
|
|
thats wrong since you have to supply it as hex value, not as dec You should not write about something you know nothing about. It only demonstrates your ignorance. The value is not hex. D:\mining\vanitygen-0.22>vanitygen64 -X 43 Jesus Difficulty: 4553521 Pattern: Jesus Address: Jesus3mWiuWzjm1NpyxUtBJdjoXxLe4bMX Privkey: 6jciffhBuFEvAj3GKpbDWRsaTTMW7kAqs2gUbX...
im not talking with morons using win lol, use the official source and you see. (ignored)
|
|
|
|