So is there anything we can do to stop it? I've been looking for a thread to post this in, but havent' found any appropriate. Forget about mod. It does not make sense for me, why the bounty manager is paying the guys LOL Check his recent post historyYou are right! On top of spamming the forum he's getting stakes for it. Yes, there are things you can do: 1) open a thread in meta (which you already did) => Hope the dude gets banned, or at least red tagged by DT members 2) report his posts to the moderator(s) => hope he doesn't get payed because all his posts get nuked, thus remove the incentive to start all over when his account gets banned 3) contact the bounty manager of the campaign he's spamming for => hope he doesn't get payed, thus remove the incentive to start all over when his account gets banned. As a matter of fact: if you contact the bounty manager and you receive no answer, it might be a good idear to update this topic with this information, maybe somebody on DT would be willing to red tag the bounty manager untill he complies in removing shitposters like this one... BTW: my eyes actually hurt after trying to read his gibberish... WTF |
|
|
|
Iemand deze gebruikt om zijn bitcoins uit te geven ? Ervaringen ?
Voorlopig is het afgelopen met Bitcoin debit karten en zie ik ook zo snel weer terug komen. How come ? Ik ben zelf geen bitcoin debit card gebruiker, maar heb wel langs de kantlijn gevolgd wat er gebeurde... Blijkbaar is er een bedrijf, "WaveCrest" genaamd dat VISA kaarten mocht verdelen. Bijna alle exchanges die debit cards uitdeelden maakten gebruik van de diensten van "WaveCrest" (maw: de exchange had geen licentie van VISA, de kaarten die zij verdeelden werden dus eigenlijk door WaveCrest uitgegeven in hun naam). Ergens begin 2018 heeft WaveCrest zijn licentie bij VISA verloren, dus werden van de ene dag op de andere bijna alle bitcoin debit cards waardeloos. |
|
|
|
--snip--
All passwords are sent or displayed to the user before going to the database and when it is saved in the database is already encrypted, this will not cause problems if the server is invaded.
--snip--
Could you elaborate on the quoted text? Do i understand it correctly if i presume the passwords go into an encrypted database, but they're stored in plain text in this database? If so, this is a huge security risk, even if your database is encrypted... I'd rather use a system with an unencrypted database that stores a salted hash of my password than using a system with an encrypted database that stores my password in plain text... |
|
|
|
Why don't you just buy or earn a small amount of bitcoin for yourself? Also it is possible, if you run your client on testnet.
Which wallet are you using for the payments? I can tell you how to activate the testnet and how to get free coin to test it out with.
Testnet would also be my first choice. Another option would be to setup a node in regtest mode: https://bitcoin.org/en/glossary/regression-test-mode |
|
|
|
Ok, but when there are "waves" of hash rate in the two weeks, the coin can not adapt.
Depending on BTC.com the difficulty will rise about 3 % in 6 days, but as I said at the moment 5 to 6 Blocks in 2 hours....
The network behaves as it was initially designed. Every 2016 blocks there is a retarget, the difficulty gets adjusted upwards or downwards so the AVERAGE time between two blocks is ~10 minutes. You are correct tough, if the networks hashrate would drop to 50% in the first 10 minutes after a retarget, it would take about 4 weeks untill the next retarget, at which point the time between two blocks would once again be ~10 minutes. This is still "working as designed" tough, theoretically, there is no problem... Sure, blocks would probably be completely full for the next 4 weeks, a fee war could start, it would take a longer time to get a confirmation,.... But everything would sort itself out, without technical problems. The fact that at this moment, the time between the last 6 blocks was ~20 minutes (i didn't verify this): no problem, it's completely possible... That's why the difficulty is adjusted so the AVERAGE time between two blocks is ~10minutes, and that's also why we don't retarget every 10 or 20 blocks (if we would retarget to often, the difficulty would jump up and down quite a bit, since the number of samples would be to low). Solving a block requires the miners to increment a nonce in the block header, then create a sha256d hash of this new header and check if the result in under the current target. It's possible that after a miner receives a new block and start working on the next block, he finds a header whose sha256d hash is under the target in less than a second, it's also possible he'll never find a valid block... |
|
|
|
Thanks for the advice. You guys have pointed me in the right redirection.
Are there any stats anywhere on how many addresses without zero balances are in existence?
I've generated a list of all funded addresses for somebody on this forum a while ago... I used this script: https://github.com/cryptah/utxo-dumpIIRC, at that time, there were ~40.000.000 unspent outputs in the UTXO set, don't remember how many addresses were funded (multiple unspent outputs can fund the same address). I can only estimate this number to have grown since then (about a month ago iirc) |
|
|
|
Or, even easier...
Start at the beginning aggregating balances. As you encounter each new block, record the block height and current balances in a database. Then when you want to know any historical balance, your can just query your database for the block height in question. Meanwhile, your node can continue to remain synchronized and can continue to update your database as new blocks are received.
Wouldn't that require a huge database? I think it wouldn't be practical to save all balances for all addresses that ever existed at each blockheight, but you could probably save balance of each address whose balance was changed by a transaction in a block at each height... That way you should be able to query the value of the sum of the unspent outputs funding address x at height y where the blockheight = the max blockheight for an entry for address x. Something like this CREATE TABLE balances (
id int NOT NULL AUTO_INCREMENT,
address varchar(45),
balance_at_height int(15),
height int(10)
PRIMARY KEY (id)
);
For example, if my address was funded for the very first time at height 40000, then was funded for a second time at 401000 and i spent both outputs at 402000, only 3 inserts would be needed for my total history... insert into (address, balace_at_height, height) values ("1MocACiWLM8bYn8pCrYjy6uHq4U3CkxLaa", 100000, 400000);
insert into (address, balace_at_height, height) values ("1MocACiWLM8bYn8pCrYjy6uHq4U3CkxLaa", 200000, 401000);
insert into (address, balace_at_height, height) values ("1MocACiWLM8bYn8pCrYjy6uHq4U3CkxLaa", 0, 402000);
Each new block you'd have to parse 1500? transactions, so if you'd only have to save the balances of addresses whose balance changed at each blockheight, you'd have to insert at least ~1500 changes/block * ~144 blocks/day = 216000 changes each day... That seems doable |
|
|
|
That makes sense.
If it is always aggregated, how are balance lookups so fast?
Because when you install a node, it syncs the complete blockchain. During this syncing, the blocks are parsed and verified, and a node builds the UTXO set while syncing (it aggregates from block #1 up untill the current height). This syncing process takes hours, sometimes even days (depending on your node's version, the IO capacity, the memory speed, the cpu,...). After the initial sync, the UTXO set up untill a certain height is built, so as long as you keep your node running 24/7, or at least start it a couple times a week, it can keep up with all the new blocks pretty fast, your node just parses a new block when it receives it, and adapts its utxo set accordingly. So, when you use a full client, your PC/server already did all these aggregations in the past, so you can now see your balance instantly. If you use an SPV client (like electrum, or most of the hardware wallets), this SPV client is connected to a full node, this node built the UTXO set in the past when it was syncing, so it can also reply instantly when an SPV client querys the unspent outputs funding a certain address. |
|
|
|
While the odds of a collision are extremely low, they rise with an increasing difficulty. And since the number of blocks is unbounded, the probability of a collision occurring approaches 100%.
Sure, given an infinite timeframe, the odds become 100%, but still, the block would get rejected, so it's just the miner who mined the block with the colliding hash loses the block reward + fees for that block, and that's about all that'll happen. In our lifetime, i doubt we'll ever see such a collision happening... My math is not good enough to calculate the exact odds tough, but it would be an extremely small number... |
|
|
|
Its possible to migrate a copy of the main ledger to a testnet and then reverse the data to a certain block for knowing what account balances were at that specific block?
Or would it be better to aggregate from the genesis block to the required block?
You always aggregate from the genesis block to the required block... The latest block does not specify all unspent outputs (which you can use to calculate the total value funding each of your addresses). Basically, a block contains a bunch of transactions. Each transaction just tells you which unspent output(s) from the UTXO set are used, and which new (unspent) outputs are generated. Offcourse, there is also some other data in a block (like the signature , the block header). In order to generate the UTXO set (the set of unspent outputs that you can use to calculate your balance), you start from the genesis block and follow each unspent output. As soon as a transaction uses an unspent output from your current utxo set, it must be removed from the utxo set, and the output of the transaction will be added to the utxo set... The coinbase transaction also generates a new unspent output. If you do this upto height x, you automatically know all unspent outputs at height x, so you can use them to calculate the balances. |
|
|
|
~snip~ Account in bitcoin daemon is more like a lable string, address is enough to send and receive coins. But if you want to set a new account for each user for management purpose, you can do that using bitcoind's rpc, refer to getaccountaddress api. getaccountaddress
Returns the current bitcoin address for receiving payments to this account. If <account> does not exist, it will be created along with an associated new address that will be returned.
I never used the accounts functionality of bitcoin core, but didn't i read somewhere it's deprecated? But you are correct tough, the only thing the OP needs is a new, unique address per user (or a set of addresses). I'd say it might be a good idear to keep the account management in a seperate database (create a small relational db and keep track of which user "owns" which addresses, do make sure you keep track of change addresses when he spends his unspent outputs!!!) |
|
|
|
If i remember correctly, this is one of the checks a node does before accepting a block... If the hash of a new block is the same as the hash of a previous block, the new block will be rejected... Source: my memory... Might not be 100% accurate  EDIT: do realise the odds of a collision are incredibly small |
|
|
|
I personally belief none of the 5 suggestions made by CryptoMauren should be considered as a safe wallet... 1. Blockchain
Blockchain is the technology behind Bitcoin's turnaround itself, so its superiority as a provider of
Bitcoin wallet is definitely beyond doubt. You can even see all transactions from all accounts,
whether it's Bitcoin acceptance or delivery.
The blockchain company is NOT the company that's behind the creation of the blockchain technology!!!!!!!!! Satoshi is the one (or the group of people) that wrote the whitepaper and the first reference client. AFAIK, he doesn't work for blockchain.com (or blockchain.info)... Well, we don't know the identity of satoshi, but the odds of him working for blockchain.com are very small. Blockchain.com = private company that specialises in implementations of the blockchain techology the blockchain = the techology behind a decentral, immutable trustless ledger on which bitcoin was built Blockchain.com != the blockchainBlockchain.info is a web wallet, which is inherently unsafe 2. Bitcoin.co.id
This one site can be regarded as the most crowded place to buy Bitcoin in Indonesia. Account
creation at bitcoin.co.id not only provides a wallet address, but also facilities for Bitcoin
transactions directly with Rupiah (via local bank payment method) and Bitcoin trading.
This is an exchange, which is even worse than your first suggestion 3. Coinbase
Coinbase.com is a Bitcoin wallet provider site based in San Francisco, USA. Coinbase's credibility
and functionality is not much different from Blockchain. But since Blockchain is a Bitcoin original
technology, it's no wonder Coinbase is a bit less popular than Blockchain.
Same as point 2... 4. Xapo
Xapo not only operates as a Bitcoin wallet provider, but also a Faucet site that can provide free
Bitcoin to its users. It also provides more convenience because users can directly enter Bitcoin
into the wallet that has been integrated with its Faucet system.
Same as point 2... 5. BitX
BitX is the second site that provides Bitcoin wallet as well as trading for Indonesian clients. But
unlike bitcoin.co.id, BitX does not accept digital currency storage other than Bitcoin. BitX itself is
now rebranding into Luno which operates as a global company and has branch offices in London,
Singapore, and Cape Town.
Same as point 2... |
|
|
|
Do you think requiring KYC here in bitcointalk a good idea? It'll prevent scammers from entering our forum plus this will also prevent Alt accounts which commonly makes a lot of spams.
No, i don't like the idear... What if the database get hacked again? The hacker would have doxxable materials on 1000's of crypto enthousiasts... Some 3 letter agencies would dream about this opportunity, as would several gangs that would now be able to come to our houses and beat up our familys untill we fork over our private keys... Bitcoin is about freedom, this includes the freedom to remain anonymous if you wish so (for example, the forum's founder is still completely anonymous). Also, bitcointalk is a community forum, so the term 'Customer' doesn't apply here (imho). I wonder if we could figure a way of putting a forum on the blockchain and decentralising the data held. Considering you said this has been hacked before. I do think there would be a huge spike in quality of material on here. You do find quite allot on non comments you have to trawl through to get to the hidden gems. Well, a blockchain is a decentralised, trustless, immutable database. Using a blockchain for a public forum is an idear that might have an application somewhere, however i don't think it's a good idear to move bitcointalk to a blockchain based data storage system. Why? Several reasons: 1) If you want bitcointalk to be 100% decentralised, you'll also need the (salted) password hashes on a blockchain, meaning that anybody anywhere will have access to the hashing function AND the hashed password (brute-force???) 2) It'll be impossible for the mods to delete spam, at least, they can probably add a block with information that disables a certain post, but the data itself will always be in the blockchain 3) thousands of posts get made on bitcointalk on any given day... Imagine the amount of data that would have to be transmitted and verified by all those nodes So, to sum it up, i don't think that a blockchain based approach is the correct approach for the bitcointalk database, it defenatly doesn't solve the KYC question made by the OP  |
|
|
|
Do you think requiring KYC here in bitcointalk a good idea? It'll prevent scammers from entering our forum plus this will also prevent Alt accounts which commonly makes a lot of spams.
No, i don't like the idear... What if the database get hacked again? The hacker would have doxxable materials on 1000's of crypto enthousiasts... Some 3 letter agencies would dream about this opportunity, as would several gangs that would now be able to come to our houses and beat up our familys untill we fork over our private keys... Bitcoin is about freedom, this includes the freedom to remain anonymous if you wish so (for example, the forum's founder is still completely anonymous). Also, bitcointalk is a community forum, so the term 'Customer' doesn't apply here (imho). |
|
|
|
I completely agree with AdolfinWolf and TryNinja, but wanted to go the extra mile and offer my "5 safest bitcoin wallets", just in case a newbie stumbles upon this thread... This way i figure he can at least leave with some safe advice 1. My absolute safest wallet: a recently compiled bitcoin core on an AIRGAPPED pc. If you can make regular offline backups and keep them safe, it might even be a good idear to configure your core wallet to be non-hd, so private keys get generated completely random (but if you do this, you need to backup your wallet.dat very regulary => https://en.bitcoin.it/wiki/How_to_set_up_a_secure_offline_savings_wallet2. A recent version of electrum on an airgapped PC... Keep the seed safe => http://docs.electrum.org/en/latest/coldstorage.html3. A correctly generated paper wallet, using BIP38 encryption with a very strong passphrase. Do make sure you follow the proper procedure for creating a paper wallet, and use a paper wallet generator with a truely vetted RNG... An offline copy of bitaddress.org usually does the trick... Make sure your pc is offline during the whole creation process, and rebooted before put back online... And make sure no copy of the paper wallet ever touches an online device (for the truely paranoid: make sure the printer used for printing the wallet is offline, and rebooted right after printing the wallet... Also, make sure you securely wipe the usbstick you used to transfer the paper wallet... Formatting or just deleting images is NOT a secure way to wipe a stick!!!) 4. Trezor model T or trezor one... Since they've been around longer than ledger, i would put them 1 place higher than ledger 5. Ledger model S Whatever you do, think about your wallet choice. If you only hold a small amount of BTC, a desktop wallet on an clean, online machine might be fine... Core or electrum are my prefered wallets in this scenario... If you hold more than 0.5BTC, it might be a good idear to invest in a decent hardware wallet or start using a paper wallet... If you hold a small fortune, it's defenatly a good idear to spread your funds, and also use a couple cold wallets to store your wealth... The only thing you should avoid (imho) is storing BTC (or altcoins) in an online wallet or exchange... If you're not the only one in controll of your private keys, you're not in controll of your funds. The only thing an online wallet is good for is to store spending money when you're away for a longer time... You know, a couple hundred bucks worth of BTC for when you're on vacation and you want access to this money just in case you find something interesting to spend it on... But even then, i'd prefer a mobile wallet to store this spending money on instead of an online wallet. |
|
|
|
in short. all Mining pools run a full node?. or some of pools are not?.
If you want to run a pool, you need access to a node... So yes, they are either running a node, or they are paying somebody to run a node they can query. The pool needs at very least the header of the previous block, and if they don't want to mine blocks with only the coinbase transaction, they also need information about the broadcasted transactions... And if they want to include these transactions, they need to update their utxo set, so they need to parse the complete blockchain... In other words: they need to run a node |
|
|
|
I don't mean to be rude. It's not me, but you who aren't listening. I don't need somebody's money. I'm trying to recover my funds. Even though everybody tells me that it's not possible. I've read about folks from LBC or BLC or whatever it is...has nothing to do with me or my goals. I would be gratefull to anybody who has something to say about a working script, besides the prognosis with possibilities rates.
In the past, i've helped people brute-forcing private keys and seeds when they forgot 1 word or 1 character from their key/seed using a python script... This actually IS possible, and that might be the thing those guys on LBC or BLC were talking about? IIRC, i got a speed of around ~1000 keys/second. There are 2^160 possible addresses, that's 1.46e +48 keys... So, in order to scan the complete keyspace, you'll need about 1.46e +45 seconds... You'll have a 50% successrate in 7.3e +44 seconds... That's about 23171956451847141650870193314249000000 years... Now, this is using one of my python scripts... https://en.bitcoin.it/wiki/Vanitygen says that if you run oclvanitygen on an optimzed system, you can generate up to 64 Mk/sec = 64.000.000 keys/second. 2^160/(64.000.000*3600*24*365*2) = 362.061.819.560.111.588.294.846.770.535.130 years to have a 50% chance of finding the private key whose hash of the public key is equal to the addres whose key you lost... But, since bitcoin is about freedom, you can always use vanitygen (as said before) ./vanitygen -o found.txt 1Myfulladdresshere Offcourese, during your lifetime you'll have a 0.000000000000000000000000000001% chance of finding a match. If you're going to burn your power anyways, you might aswell buy an ASIC, unless you lost an address that had several 1000's of BTC you'll probably make a lot more by mining than by brute forcing... (btw, i'm not saying that you HAVE to mine... If you don't have basic knowledge, luck AND a good power rate, you'll lose money while mining, but still the odds are really big that you'll have less net loss than when you try to brute force your pk) |
|
|
|
I've been using my staked vanity address 1MocACiWLM8bYn8pCrYjy6uHq4U3CkxLaa for business purposes and tipjar purposes for a really long time... I'm now thinking about claiming some of the forked off altcoins that have unspent outputs funding this address... Because i'll probably be importing my private key into a couple of wallets i don't fully trust, i'll be staking a new vanity address. This new vanity addresses's sole purpose will be to sign messages, so i'll probably never have to change it again: 1MocacinXMCF96Gs3CSp7p2NrjhFXe3Wuv -----BEGIN BITCOIN SIGNED MESSAGE----- I'm mocacinno, i'll be using vanity address 1MocacinXMCF96Gs3CSp7p2NrjhFXe3Wuv for signing messages from now on. This message is signed with my old vanity addy to proof i still hold its private key to! Today is the 30th of april 2018 -----BEGIN SIGNATURE----- 1MocACiWLM8bYn8pCrYjy6uHq4U3CkxLaa G9wc0ZkX3luA2DBBR7kFs66wmGuvY0l8+Edq2c2UPGrSWrfKtJmr/1LYKqMylEhn/jtoMt5lwaO2b2sXvwDXFH4= -----END BITCOIN SIGNED MESSAGE----- I've verified the message using https://blockexplorer.com/messages/verify and it was valid... I know how to sign messages anyways |
|
|
|
The ICO part turns me away from this more than anything, and the picture of their miner on the page you linked is extremely low quality and grainy. I like new miner developments, but there's just very little information about these miners out right now and whether or not they're actually real, and I don't trust ICOs much at all (GMO comes to mind with miner ICOs). I guess time will tell if this is legit or not.
My sentiments exactly.... I don't trust the fact that they're running an ICO, i don't trust the fact that they try to lure in new buyers with a 50% bonus for the pre-sale, i don't trust the fact that without the bonus they predict a 3 month ROI on the smallest investment. But you're right: only time will tell if my gut feeling was correct on this one |
|
|
|
|
Show Posts
