I think cloud mining defiantly belongs somewhere in the mining section as cloud mining is a way people can mine bitcoin.
IMHO, anything where you can say: "contact support" to someone having problems should be in the service section, as you are indeed using a service with its own support system in place. The support might be bad, but thats not the point. The fact that most cloud mining services only allow users to mine via their own pool would mean that the majority of cloud mining threads would belong in the "pools" subsection in mining,
I disagree because if someone has no choice over the pool, the pool does matter little and can not be meaningfull discussed. although many would also belong in the "speculation" subsection as many of them are speculating that cloud mining services are ponzis/scams.
There is a mining speculation section that deals with the profitability of anything related to mining. "Is this cloud mining profitable" should belong there as well. I am not sure how many cloud mining services there are out there, nor am I sure how many threads relating to cloud mining are created/are active, so I am not sure if it's own subforum section would be warranted.
|
|
|
|
Sorry,
habe jetzt das Script pywallet.py ausgeführt.
was muss ich jetzt mit den extrahierten Infos machen?
Erzähl doch mal von Anfang an und Schritt für Schritt. Das letzte mal als ich pywallet ausgeführt habe, hat mich niemand nach Infos per Mail gefragt. |
|
|
|
Why would anyone use anything other than brain wallet?
Because people are bad at "random". Plenty of brain wallets have been "hacked". I have a hard time calling it a hack honestly, its more like guessing your phrase and boom your bitcoin belong to me now. I mean installed on your own computer, not running on someone else's server.
installed? I am not sure you understand how a brainwallet works. Is there some reason why it is not the most secure, easiest to use wallet on the planet?
Please explain what exactly you understand a "brainwallet" as and Ill gladly point out its flaws. |
|
|
|
There are also open source (free) solutions. btcrecover is one, although it's more difficult to use... Thanks, I knew there was one I missed. Is this yours? nevermind, a click on your profile was enough  |
|
|
|
Nop it has been completed
Sometimes problems solve themselves. If you still want to change to Electrum the easiest and safest way to do so is to make a transaction to one of your own electrum addresses. If using electrum make sure you have a proper backup of the seed, e.g. on paper at different places and/or in digital form in an encrypted container with a reasonable strong password. |
|
|
|
-snip-
also wenn ich in den bitcoin Umrechner 0,0001 eingebe nimmt der das als 1 also 295,93...du meintest schon 0.0001 also 0.03 Euro, oder??!
Die englischen Seiten benutzen "." statt "," um Dezimalstellen zu Kennzeichnen. "," ist bei denen das Trennzeichen für tausender. Zehntausend sind also 10,000.00 statt bei uns 10.000,00. Ansonsten würde ich Dir raten es langsam anzugehen zu lassen. Egal worum es geht. Bitcoin ist immer noch ein bisschen kompliziert für einige Menschen und offenbar werden Dir komische Dinge erzählt. - "doppelte Gebühr wenns schnell gehen soll" - das doppelte wovon weiß ich jetzt nicht, aber das klingt als möchte Dich jemand über den Tisch ziehen. - "Wallets kosten Geld" - klingt ebenfalls nach Abzocke. Am besten postest Du hier im Forum [1] und achtest darauf mit jemandem zu Handeln der Erfahrung hat, auf "trust" klicken und in Ruhe die Referenzen durchlesen. Der trust link ist nicht in allen Unterforen zu sehen. ah okay,
bei BTCdirect stand nämlich, das würde 10 euro kosten oder so..
Danke für den Link.
BTC zu kaufen kann durchaus mit Gebühren verbunden sein. [1] https://bitcointalk.org/index.php?board=36.0 |
|
|
|
Yeah, I've read the dev documentation. But I need more than that. Well, for instance, you said nodes have a banscore. Where is that banscore stored?
In memory. If you enter getpeerinfo in the console or if you use bitcoind getpeerinfo from a linux terminal on a machine that allready has bitcoind running you get something like this: [
{
"addr" : "-IP-:8333",
"addrlocal" : "-IP-:8333",
"services" : "00000001",
"lastsend" : 1417103014,
"lastrecv" : 1417103015,
"bytessent" : 426967,
"bytesrecv" : 28102212,
"conntime" : 1417095403,
"pingtime" : 0.00000000,
"version" : 70002,
"subver" : "/Satoshi:0.9.2.1/",
"inbound" : false,
"startingheight" : 331833,
"banscore" : 0,
"syncnode" : true
},-more nodes here-
]
I currently have none with a banscore >0. But this information is gone as soon as you terminate the client/daemon. In the block chain? I don't think so. And, is that banscore written to the IP address of the node?
Yes, its per IP and each node has its own list for the banscore. You can modify your tolerance for it in the bitcoind.conf file if you want and a custom written client might also write it to disk when shutting down. And if such a thing exists, can there also be a banscore for the spammers? Then, an IP based spam prevention would be possible, instead of the fee structure.
Well, AFAIK the reason behind the banscore is to prevent a DoS attack not transactionspam. A DoS or even DDoS attack would simply fail because of the banscore system. An attack with cheap data of invalid transactions would only result in an increasing banscore and finally in a disconnect. The invalid transactions would not be relayed to the network, thus unable to bother all nodes at the same time. Over time any attacker(s) would run out of IP addresses and can only ever bother a few nodes at a time. The fees exists to make mining profitable in the long run. In the distant future when the blockreward is so small it is no longer of relevance or even shrunk to zero, the fees will be the payment for the miners to keep going, to keep mining profitable. The relay rules are what currently prevents transactionspam, or rather what makes it harder to spam with 1 satoshi TX. If you look at the rules in the "isDust" function I linked earlier you will notice that a dust transaction is actually valid and might be even valueable in the future. Currently dust transactions are not relayed by bitcoin core, but kept in memory as valid transactions. This makes it harder for spammers as they cant just broadcast their transactions to any random node and hope that the network will know about the transaction within seconds. They still happen though, since not all the nodes run the same version and possibly some spammers have access to reasonable hashingpower. Usually its done as a sort of advertising and would include a tag on blockchain.info |
|
|
|
shorena,
Thank you very much. You're my saver. I am trying to learn how the network works in detail bit by bit. Unfortunately, it's really hard to delve into the code directly. So I need a guide like the answer you gave. Thanks again.
You are welcome. You can also read more in the dev doc [1] I guess its more helpfull than the code itself. [1] https://bitcoin.org/en/developer-documentation |
|
|
|
ok, bitcoin core synced and got btc on it, coin control enabled but i don't understand it
what to do now? if i just want 2 transactions to repeat all the time (seperate tx id's)
Its not an automated process. Its the buttons you have to click on order to create a single transaction. |
|
|
|
So you are saying there is an equivalent of 95% of todays hashingpower somewhere in a warehouse just waiting for this to happen?
Nope, im saying if mining would be 95% easier new miners would pop quicker than you can think of True, I suspect that as well. I however doubt that it would be enough to reach "100%" again. If it would be "easy" to gather as much hashingpower as currently is around a 51% attack would be "easy" as well. I doubt recovery would be a matter of days, weeks or even months are more likely. |
|
|
|
Hi,
Satoshi et al. has written so little on how the network operates. Can someone offer me a good read, other than the source code?
I am especially curious about how nodes broadcast. For instance, if someone having zero balance tries to send some bitcoins to an address, the standard bitcoin client wouldn't allow it. But it should be easy to change the code so as to allow broadcasting such an invalid transaction. Then, when peers get the transaction request, do they check if it's valid or not before they send the request to other peers?
Or do I understand the process completely wrong?
-snip-
Yes each transaction is checked when received against a certain set of rules. If the transaction is invalid it is dropped from memory and the node sending it gets a little banscore. If the banscore reaches a certain amount no more connections and or transaction from that node are accepted. There is also a set of rules to check if the transaction should be relayed. E.g. a TX sending 1 Satoshi is valid, but bitcoin core would not relay it. If each node checks if a transaction is valid or not, then it means each node is responsible for the security of the block chain, not only miners. Is that correct?
In a way yes. Another thing is, when downloading the block chain, does a node checks if all the transactions in each block are valid?
Yes, each block is checked and only accepted if correct. If you can show me the portions of the source code which deals with those issues, please show me where to look.
Thanks
You can use the search function here [1] e.g. the is it dust check can be found in the transaction.h [2] [1] https://github.com/bitcoin/bitcoin[2] https://github.com/bitcoin/bitcoin/blob/df504e924a57fac331babef31420e257d332aa64/src/core/transaction.h#L137 |
|
|
|
I thought that if you forget the password it is not possible to get to the wallet
If you have no idea what the password is, it is indeed not possible to recover the wallet. But usually people remember most of the password or have a certain system behind it which helps to remember it. If you know enough about the password a script can be written to check for the remaining uncertainties. The more you know the higher the propability of a recovery. |
|
|
|
95% of miners are suddenly offline. Be it a new law or an EMP strike. What would happen to bitcoin?  That is impossible to happen and even if it would, nothing impotant would happen  , new miners would rush for free money. So you are saying there is an equivalent of 95% of todays hashingpower somewhere in a warehouse just waiting for this to happen? |
|
|
|
-snip-
That'd be a hassle I guess. Zero-confirmation services would then explode, correct?
I suspect there would be more demand for offchain services but at the same time 51% attacks and other possible attacks would be easier, thus requiring for more initial confirmations to mitigate the effect. IMHO the best action would be to reactivate old mininghardware and only spend btc if you absolutly have to. If I had to make or accept a TX, Id require more confirmations than now. Not sure about how many, probably over 10. A deal would take over a day under those conditions, even longer with escrow. |
|
|
|
Value would increase? With a sudden cap on "incoming" currency, I think the economic value would substantially increase.
I don't think so, since it would be bad PR for Bitcoins. Transaction would take longer to confirm, which would really hurt. But the difficulty is adjusted every two weeks, so the effect on the network would be gone after that period, but still bad PR. This is not true. The difficulty adjusts every 2016 blocks so that the previous 2016 blocks would have been mined in two weeks had the difficulty be what it was changed to. Assuming that 95% of the miners go offline exactly as the difficulty chances and ignoring variance, and assuming that no additional miners come online or go offline then it would take 40 weeks for the difficulty to adjust. However the likely result of the miners going offline is that the TX fees would skyrocket which would entice other miners to go online as the EV of mining would increase. Does this mean confirmation will take about 3-4 hours? On average a confirmation would take 200 minutes, yes. |
|
|
|
-snip-
I'm still a somewhat novice to the whole process, but do transaction confirmations require miner interaction?
Yes, you broadcast your transaction (TX) to all nodes you are connected to. These check if your TX is valid and safe them in memory, if they also meet the relay criteria they are broadcasted to all other nodes they know. This will - for regular transactions - result in the whole network knowing about your TX in a few seconds. The miners are those that take these TX and put them into a block. Once your TX is in a block it has its first confirmation. Each block after the first will increase the number of confirmations by 1. The picture shows the number of TX my node knowns about. If they suddently drop a block was found and confirmed those you no longer see on the graph.  |
|
|
|
95% of miners are suddenly offline. Be it a new law or an EMP strike. What would happen to bitcoin? Confirmation of transactions would take longer untill we hit the next difficulty adjustment. After that difficulty would be decreased. I am not 100% certain if there is a maximum the difficulty can change per adjustment, but I suspect there is. |
|
|
|
I can handle it for you no problem. Send me a PM with your shipping details!
If anyone else has met the requirements feel free to message me and I will get your coin shipped out. (Nightowlace will most likely be afk for a week or two).
Thanks, you have a PM. With this news do I have to wait until the 29th of this month? I've already posted 200 msgs so I already mee the requirements
The requirements are over xxx posts and 60 days, if you have met both, write Blazedout419. He is working for silverwallts.com as well. Check the posts in this thread to verify. He accepted several participants and handled the design contest. |
|
|
|
@ArpFlush could you post an image with the key pair? It is not useful for you, isn't it? I would like to see it by myself.
Sure: (sorry for the upside/down) fixed that for you:  Edit: private key: 5KaDTTWPxdwxrFYboxQPJiXgqwua9SULLCvLFEBuGkbeQnSLAoG results in address: 16obDHVzXx1YevqkAkDyN5Vbqw4V8iauGf according to brainwallet homepage [1]. [1] https://brainwallet.github.io/ |
|
|
|
|
Show Posts
