I am using the version 3.4.0 BFGMiner that is distributed as part of Bertmod 0.3 on my KnCMiner Saturn. I added the lines: "coinbase-addr": <my payout address>,
"coinbase-sig": <My block sig>
to the end of the config file, because I wanted to solo mine on my local bitcoin-qt. It doesn't generate any errors, but the hashrate goes down from ~285 GH/s to more like 10 GH/s  If I remove the above two lines, it goes back to normal. Anybody have any idea what is going wrong here? Is it using 100% CPU, or less? I wonder if the BBB can't keep up with generating work via GBT... |
|
|
|
If it's this important shouldn't Eligius start forcing new addresses for every withdrawal? Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time. Unfortunately, wallet software has not matured enough for that yet. So you don't support using new addresses, but think everyone else who doesn't support it should be punished? Isn't that a bit hypocritical? I think this move should have waited a few more months at least, but we're out of time it seems. In other words, I would vote "We should have waited longer, but I guess it needs to move forward now." |
|
|
|
You're an idiot, don't do this! - 59 (36.6%)
I don't like this, but I agree we need to move forward with it. - 14 (8.7%)
We should have waited longer, but I guess it needs to move forward now. - 19 (11.8%)
Great, it's about time! - 23 (14.3%)
You're a hero, let's get this deployed everywhere ASAP! - 35 (21.7%)
If it's from Luke, it can't be any good. - 11 (6.8%)
I read the poll more along these lines. Opposed: 43.2% In favour with varying degrees of support: 56.5% Rounding 0.3%. There is a fair degree of support for this. We must also keep in mind the following
i coloured it because for instance saying "i dont like this" 14 (8.7%) means literally i dont like this.. in other words NO saying "we should have waited longer" 19 (11.8%) means literally i dont want this to be done yet.. in other words NOT YET but both questions are worded to then subtly suggest they agree to implement it. these type of questions are called trick questions. EG if i said "do you hate termites" and you chose 1) i dont like them, but i agree we to live along side them as they are living creatures great using that answer, you have agreed to allow me to deliver 500,000 termite larvae to your house as you seem to be ok with it. To quote the termite example. It is more like I am not ok with allowing you to deliver 500,000 termite larvae to my house; however if you do I will not call the exterminator even though the termites will demolish the house. The trouble with saying "no but" is that more often than not it means "yes". No... Options 2 and 3 are more like "I don't really want to pay for a security system, but if people are going to start burgling my house, I want one." FWIW, I personally am in the "We should have waited longer, but I guess it needs to move forward now." boat. |
|
|
|
Have you considered including your favorite build of hidapi in you git/configure? No, I consider it a bug to embed libraries in software. The only reason I still do it with libblkmaker is that no other software is using it yet. I ask because Arch does not have a package for it yet and I prefer you build than one I can come up with (not that my builds are bad and don't work, just because you know the ins and outs of it better than I). I have never used Arch, let alone made a package for it. Perhaps whoever is maintaining the BFGMiner packages would be willing to do this. Fair enough, I would like to contend that hidapi is in the same boat (as you described) as libblkmaker though. I will defend your choice to include those libraries because they make a better bfgminer. Why one and not the other? Perhaps not many, but there are other software using hidapi. |
|
|
|
Hi luke, i just install bfgminer on raspberry pi wheezy. All workfine and i can run ./bfgminer. but after plugin the nano fury it said permission denied. pi@raspberrypi ~/bfgminer-3.6.0 $ ./bfgminer
-bash: ./bfgminer: Permission denied
My only guess is you built it on a vfat filesystem (why???) |
|
|
|
... there are projects in the works to make anonymous commerce just as safe (or safer) as non-anonymous commerce, in a grandmother-friendly way. Bitcoin is never anonymous, no matter how you use it. After that's done, law enforcement can shove their desire to spy on everyone and everything up their ass. Law enforcement can do forensics the same way they do with cash (actually, they can do better with Bitcoin). This only buys you privacy - without it, everyone would be able to see everything you do. I think he's saying that these clients are missing bloom filter support, which has been standard for a while. Are you sure Bloom filter is the right solution? It creates more load on Bitcoin nodes than UTXOs-for-address queries would. "Lookup by address" is only less load than "lookup by bloom filter" if every node carries an address index (which adds to disk and memory requirements). In any case, Bitcoin was designed with addresses being single-use, and it becomes unusable with too much reuse, so this side-topic is irrelevant. |
|
|
|
I've argued with Luke before on this obsession of his, your never going to go mainstream with something that dose not give people DURABLE identities. Disposable identities are never going to fly in mainstream commerce where law enforcement must be conducted. Bitcoin does not provide identities of any sort. If you need identities, use PGP. Also you have the grandmother factor at work here, ... Payment protocol should make things easier. |
|
|
|
Thin wallets like Electrum and blockchain.info retrieve UTXOs from server, and cost for server is roughly proportional to number of addresses used, so address re-use improves efficiency. Are you against that?
Are you saying that address reuse makes the UTXO set smaller? I think he's saying that these clients are missing bloom filter support, which has been standard for a while. |
|
|
|
So let me get this right: A mining pool operator implemented a change that, with (wider) acceptance, would delay payments to his own miners? This isn't correct. If a mining pool paid people more than once per block, there's something more subtle wrong... Should his miners change their payout addresses every single mined block? They should use Bitcoin recurring invoices (BIP32), not addresses. BIP_32 is not in effect, so that argument is currently moot. Bitcoin is still beta and incomplete. |
|
|
|
i am getting staged work underrun; not automatically increasing above 23 my hash rate is ~410gh running 13 Chili's with a diff of 512 i have tried diff 128, 256, and 512 running bfgminer version 3.5.0 compiled from git. is that caused by bfgminer? and would 3.5.2 help? In other words, everything is fine? |
|
|
|
Have you considered including your favorite build of hidapi in you git/configure? No, I consider it a bug to embed libraries in software. The only reason I still do it with libblkmaker is that no other software is using it yet. I ask because Arch does not have a package for it yet and I prefer you build than one I can come up with (not that my builds are bad and don't work, just because you know the ins and outs of it better than I). I have never used Arch, let alone made a package for it. Perhaps whoever is maintaining the BFGMiner packages would be willing to do this. |
|
|
|
i just grabbed a random block http://blockchain.info/block-index/440384/0000000000000000a1bf1c65136cbd618e356179fec857d583e7a9373ca8386d (269989) and looked at the transactions in it.. within the first 20 transactions there were around 10 where the destination was at that time used address. so is Luke JR telling us that the first transaction goes into this block(2699 89) the next transaction has to wait for the next block(2699 90) and so on for the 10 addresses i looked at(2699 99) that there is causing atleast 1 hour 40 minute delay for that 10th transaction. and what about other transactions sent 10 minutes after(269989). they have no spaces in block(269990) through to (269999) so lets say there were 10 used addressed transactions per block in block(269990). after waiting 1 hour 40 minutes, each of those 10 transactions have to wait a further 10 minutes filling up blocks (270000-270009) . making the 10th transaction sent at the timestamp of 269990 finally enter a block over 3 hours 20 minutes later now imagine the transactions timestamped at the times of blocks 269991-270009.. imagine how long they have to wait. (300 transactions of used addresses waiting......) Luke JR i guess you never watched the butterfly effect, or what happens when you throw a pebble into the water.. The point is that people need to stop this bad behaviour and start using Bitcoin correctly. |
|
|
|
A question for the OP: Are you proposing this just for addresses that are reused after a output, (where the privacy risk is highest), or also for addresses that have multiple inputs but only 0 outputs before the transaction in question? The risks (which are not limited to mere privacy, I might note) are the same for both of these cases. In any case, while I did only provide a single patch upfront, my proposal is to discuss and implement a variety of possible solutions, not any single solution, in the short-term. |
|
|
|
Luke, can you describe more clearly what the patch does?
in particular:
- one reuse of any given address per block, or one address reuse per block?
- does it concern only inputs, outputs, or both? for example, an address
that has several inputs and tries to spend them all is deprioritized or not ? This first patch just rejects from your memorypool any transaction which: - Sends to a scriptPubKey which is already sent to (output) by another transaction in the memorypool.
- Sends to a scriptPubKey which is already being used to redeem a coin (input) by another transaction in the memorypool.
- Sends to the same scriptPubKey in two different outputs, within the same transaction.
- Uses a scriptPubKey to redeem a coin (input) which has already been used to redeem a coin (input) by another transaction in the memorypool.
And then there's Blockchain.info. Did you know Blockchain.info wallets reuse addresses by default unless you create new ones? Any software which reuses addresses by default is broken. I am okay with forcing incompetent* software developers to fix their software. * Sorry, they should really know better. I assume this cannot affect the prioritisation of the Coinbase transaction that constitutes p2pool miner's reward payments? Can you clarify this? This will not affect any generation transactions, nor any miners who choose not to use it. |
|
|
|
If it's this important shouldn't Eligius start forcing new addresses for every withdrawal? Yes, migrating to HD/recurring invoice ids has been on the todo list for Eligius for a long time. Unfortunately, wallet software has not matured enough for that yet. |
|
|
|
Not sure what you point was. The title is "DEPRIORITIZE" and that is exactly what it would do. It creates a method for privacy and security minded individuals to create an incentive for like minded individuals. Nothing more. Nothing is being forced. Nothing is being prevented. I know this is slightly off-topic, but why is it not being forced? Why not have that stuff as a fundamental part of the protocol? It seems that address reuse is causing nothing but harm, and after reading this thread, I don't see any legitimate reason why it's absolutely needed. So why not just eliminate address reuse altogether? It could be forced, but existing clients couldn't cope with such a change very well. Furthermore, in the meantime address reuse has gotten way too common for donations, so will need some gradual change. Finally, it's uncertain and unlikely that 51+% of miners are willing to shutdown this tolerance entirely right away. If there was a clear agreement from maybe 75% of miners that this needed to be done, though, it could be... |
|
|
|
I voted for "don't do this". While we should definitely encourage people to use bitcoin in privacy-friendlier ways, we should not force it upon them. We should simply make it a default, but still an option. We've been doing this since Satoshi first released Bitcoin... The problem now is that unless we force strengthen this good behaviour, other interests will start forcing the bad behaviour. People like vanity addresses. Great, vanitygen has a -k option just for this! Donations need single addresses. No, they don't. Privacy should come at the CHOICE of the user, not the FORCE of the miners. Address reuse forces non-privacy on other users. If everyone is using Bitcoin correctly (ie, no address reuse), people can still choose to publish their transaction log. That is, address reuse takes away the choice; forbidding it does not. |
|
|
|
I have a business like a gas station or a fast food, in order to actually serve all my customers and have the bitcoins in my account (transaction confirmed) Why do you need that? Do you accept credit cards? Do you wait for them to confirm as well (6 months)? with this limit of 1/block or 250/day I would have to use multiple addresses. You have to use multiple addresses anyway. "Addresses" are badly named: "invoice id" would be more accurate. What will happen if you have 1000 customers a day ? If you use the same address all the time, it'll be impossible to know which of the 10 or so paying-right-now customers failed to pay their bill. |
|
|
|
So you mean BTC is mainly adopted by people wants 100% privacy? On the contrary, it's possible that the majority haven't adopt BTC just because of the anonymity. Most of people heard of BTC but haven't convinced to use them because they think the government will not allow such things to exist. The main objective of BTC foundation is not to increase its anonymity, but to explain to the authority that it's not as anonymous as they think. This isn't about anonymity. If the government wants to know who you are, they'll subpoena your landlord to tell them. Are you saying the majority of people want the unknown to-be-rapist down the street to know their every purchase, telling him where you've been and what you buy? They want the pedophile-to-be to know when and where they drop their children off at childcare? |
|
|
|
One very common scenario is to use a bitcoin address as the identification. This may be used in faucets, mining pool, gambling sites, and maybe future block-chain based exchanges. If address reusing is discouraged, any alternative is suggested? To introduce another identity-> bitcoin address translation layer? Address-as-identity does not use the blockchain at all. If people want to hide their trace, they can choose not to reuse addresses. If people don't care, why have to increase the difficulty for them? Why not just let the users to make the decision? Reusing addresses doesn't merely hurt your own privacy. It hurts everyone's. There are also security ramifications. And now adoption issues too. |
|
|
|
|
Show Posts
