|
shitcoins and scamcoins are premined and distributed using ICO's. Good, open source, community coins that add value are not premined and wouldn't touch the ICO concept with a ten foot pole (just my own opinion tough).
At the start, anybody could mine bitcoin if they wanted. If you found a block header whose sha256d hash was under the current target, and you used one of your own addresses in the coinbase transaction, you got 50 BTC (plus fees).
You could have done this without telling anybody, so nobody knows exactly who mined these first blocks, eventough some early miners are know to the world
|
|
|
|
I'm going to leave a quote from Satoshi (can't find the exact source tough): don’t trust, verify.
It's not even about trusting the fact that you did a good job... I don't know you, but you're probably a lot smarter than me (I must honestly say I wouldn't have a clue as to where I should start when creating a hw wallet). It's all about the fact we should not have to trust your word when you tell us you created a propriatory algo to derive keys, or when you tell us you used community standards to encrypt backups.... Bitcoin's community is trustless, we want to verify (or at least have a Dev we know verify the code). But, I feel we'll never agree, so I wish you the best of luck with your company, and j hope you take the feedback you received to heart when you make decisions for your future products.... But in the end, it's between you and your customers. I just hope you'll stick to your word and release your decryption tool if you ever go bankrupt... |
|
|
|
|
I don't want to get dragged into this discussion, but the direction it's taking more or less forces me to post...
You tell us you might not release the decryption tool because it would allow somebody with access to a lot of resources to reverse engineer your tool and use the knowledge to decrypt somebody's backup.
This is a valid concern, but this kind of tought pattern comes at a price: if you don't release the source code of a working decryption tool, how will we ever be sure our backups are safe? For all we know, you might be encrypting the backupset using Des or rc4, or, God forbid, an algorithm you yourself created...
Delivering no, or a back box, decryption tool requires a lot of trust from the crypto community... Trust you have not yet earned...
If you are so worried about releasing a decryption tool, it makes me wonder how those backups are encrypted... If you messed up, a 3 letter agency won't need any tools released by you, they'll be able to decrypt our backups just fine... The only way for you and the community to be certain about the security of the backup encryption is if we can look into the tool's source code... Only if we see the code and it's inspected by some trusted devs will I put any trust in the tool and your product...
Open source decryption tools will make your backup safer. If weaknesses are found, the odds are much bigger they're going to be reported for a bug bounty so you can at least fix them
|
|
|
|
3. ATM can't take anymore cash at present.
AFAIK, electrum doesn't have a limit (well... Theoretically, there'll always be a limit, since electrum is written in python, the maximum value of a float variable is 1.7976931348623157e+308*). ... Addresses don't have a limit (well... Theoretically, i guess one address can only be funded with a little less than 21.000.000 BTC)... The only real "limit" is probably imposed by the ATM vendor. Either his software is buggy, or his ATM is broken, or his ATM software has built-in checks that stopped you from purchasing BTC. At any rate, this isn't an electrum problem... You'll have to contact the ATM's customer support to get this one sorted out. Good luck! *https://stackoverflow.com/questions/3477283/what-is-the-maximum-float-in-python |
|
|
|
Exchanges don't even need to "fall in the hands of authorities". They are quite willing to hand over your data whilst still operating. Just ask any of the thousands of Coinbase users now getting hounded by the IRS for tax money.
Exactly, this was my main point... Sure, mixers *could* fall into the hands of the authority, they *could* be honeypots... However, exchanges usually have a direct link to the governement built-in as part of their procedure. The argument that it's better to use an exchange to mix your coins instead of a mixer because a mixer *could* be forced to hand over (hopefully nonexistent) logs in case they ever get traced is false (imho). Using 2 or 3 mixers in a chain would decrease your risk even further, especially if you work over tor... As for the trust factor, do you know how many exchanges pulled an exit scam/went bancrupt/got hacked over the last couple of years? Don't trust anybody, that's the main idear... |
|
|
|
|
simple: mixers are created to provide you anonimity, exchanges are not...
Exchanges usually require KYC info, they keep logs of all addresses, ip's, timestamps,... Mixers promise to do none of these things. If a hacker hacks an exchange (this is pretty common, happens all the time), he'll be able to link all of your wallets together (sending, exchange wallet and receiving wallet) AND he'll be able to link this info to your KYC documents, ip's, browser signature, timestamps. Same goes for 3 letter agencies requesting all the exchange's data. Thus, by using an exchange as a mixer, you can actually end up DECREASING your privacy instead of increasing it.
Ofcourse, a mixer can actually be a honeypot setup by a 3 letter agency, but if you trust the mixer, it's much more anonymous than an exchange.
|
|
|
|
An autobuy link posted by a newbie, immediately vouched and cheered on by other newbies always makes me suspicious.... If you buy this code, you risk being scammed or worse at every step you take: - the op can scam you with the autobuy link
- the code can be expired
- the service itself can be a scam (I never heard from them, and I wonder why anybody would sell their coins for such a reduced price if they can clean them pretty easily AND have no guarantee the coins they receive in exchange are actually clean)
- the escrow can scam you
- and even IF the code is legit, the service is legit, the escrow is legit, YOU'll have to clean the coins... And by doing so, you helped covering up an illegal action
|
|
|
|
You created a new post to reply to an 8 year old topic? Why would you use a thirth party tool if you want to encrypt a file? The standard encryption used when you lock your wallet should certainly be sufficient, but in case you don't trust the core dev's, you can always just use openssl instead of searching for a binary tool that could potentially steal your wallet... openssl enc -aes-256-cbc -salt -in wallet.dat -out wallet.dat.enc
|
|
|
|
|
Just run a full node of whatever coin you want to accept and use the json-rpc interface... generate a new address for each client and keep a database that connects the client to the address...
Coins using the bitcoin codebase use more or less the same json rpc commands, coding something like this should be fairly simple... Altough i would advise to let a senior dev assist you... A simple mistake can have serious consequences, altough, as long as you keep your wallet locked, it should be fairly safe.
|
|
|
|
|
Sorry, i'm a bit late with my reply about math.random(). I'm a big fan of your site, but i'd like to see a warning banner: "for educational purposes only" on the very top.
The "problem" when people would use this site to create an "actual" private key goes further than the cryptographic insecure javascript function... Your site is (more or less) a new brainwallet.
Sure, a completely random pattern is impossible to bruteforce... A random pattern created with math.random is *allmost* impossible to bruteforce (actually, i believe it's still impossible, even with the weak math.random function, but still...). BUT, a brain is a terrible source of entropy (i don't know who first came up with this quote, but i really like it).
This basically means that IF your site becomes popular, and a million people use it to "draw" their private keys, i can pretty much guarantee that if I would generate a dictionary of the one million most popular images and shapes, convert it into 16x16 pixels, convert it to a private key => public key => address and check the address for unspent outputs, i'd find several dozen of funded addresses i'd be able to rob.
Don't get me wrong, you wrote a nice learning tool, it's fun to see and it can teach people about the basics of key and address generation... However, i would NOT recommand to "draw" a drawing you can easily remember, and fund the address that was actually generated as a result of this drawing, nor would i use the random function due to the cryptographic weakness.
Conclusion: nice tool, nice for learning, nice for visualising a pregenerated private key on an offline machine, nice for playing, not ideal for actual production key generation
|
|
|
|
|
I wouldn't download the blockchain via torrent... Not as safe as downloading the blocks from several peers, and you still need to verify and parse the blocks... My advice to you would be to either find the bottleneck on your system or switch to an SPV wallet... SPV wallets only download the block headers, it takes a couple minutes to sync and uses a couple dozen Mb of diskspace.
|
|
|
|
I can see this being an issue if the users had to construct the multisig address themselves. Why don't people use Bitrated though? Do people not trust that it's constructing the 2 of 3 correctly? Or is it still too complicated? Or do people just trust the arbitrators on bitcointalk so much that they don't see the value in having even more security?
I have never heared about bitrated, so i don't really know how they work... But trusting a thirth party to generate a 2/3 multisig wallet seems unsecure to me... What if bitrated records all keys? Every party would think they're secure, but bitrated would still be able to run away with all the funds... Unless the keys are generated 100% client side, but like i said: i don't know bitrated... |
|
|
|
|
@go1111111: yes, every time i used an escrow on this forum, the escrow process involved funding an address generated by the escrow agent, and not creating a 2 to 3 multisig wallet. That does NOT mean your assumption is wrong tough... It would probably be safer to use a 2/3 multisig so the escrow agent can't just run away with the funds... He can still conspire with one of the involved parties to steal the funds together, but at least he can't just run away without help from either the buyer or the seller.
As for the reason why: my best guess would be it has something to do with the technical experience of the average user. An escrow agent has a lot of responsibility and has to deal with inexperienced users asking "newbie" questions all the time. I wouldn't be surprised if most escrow agents had issues with people not understanding the basics of crypto currencies and starting to make a fuss because they did not understand what was happening. If you'd add a step to your escrow process that involved creating a multisig wallet, inexperienced buyers would just lose their minds... But again, this is my gut feeling... If i were an escrow, i'd rather just skip the hassle of getting a newbie to the point where he/she can co-create a multisig wallet, and just let him/her fund an address i completely controll.
|
|
|
|
|
@coinmallio: what happens if you turn out to be a scam?
Sure, the trusted escrows don't have access to the funds, but YOU do....
|
|
|
|
I tried to distill the 3 "main" questions from your post, and tried to answer them individually If 1 computer reject the transaction, is that is going to keep it in mempool?
no... If a node rejects a transaction, the default behaviour is not to store it in it's mempool... Theoretically, i guess you can change the sourcecode and store rejected transactions in your mempool or relay them, but not select them to get included in a block... But i don't see any reason for such a patch (i guess you'd have to rewrite a lot of sourcecode to implement this behaviour) How many computer need to say ok so that the assembler include the mempool transaction into the blockchain?
only one. If a node accepts a transaction, stores it in it's mempool, is used as a mining node, inserts the transaction in the block the miner is trying to solve, and if this miner finds a block header whose hash is under the current target, the transaction is included in a valid block... However, you're talking about forking... If your fork has different consensus rules, and the tx is accepted by one node, but rejected by a different node because this second node has different rules (because of a hardfork), the second node will not accept blocks including the offending tx, while the first node accepts this block without a problem Imagine that you fork your coin, not everyone is going to upgrade to the new version, so it might do a mess with some wallet accepting the transactions, some not accepting and the blockchain will be fragmented?
Not fragmented, but there might be a fork... It might be a good idear to use checkpoints when implementing new rules... |
|
|
|
|
+1 for LoyceV's comment...
I just wanted to add that even dealing with an account with massive positive trust and a long line of escrow experience doesn't protect you 100%... I clearly remember the master-p fiasco... Luckily i was one of the members that did use him in the past, but didn't have any active trades using his services at the time he went full scam.
If you want extra security, you can always use multiple trusted escrows using a multi signature wallet (but even then, no 100% guarantee). But if you use, for example, 4 highly trusted escrows that are not connected, and create a 4 out of 6 multi sig wallet (one key generated by each escrow, one for the buyer and one for the seller), the odds of being scammed become really, really, really small
Using an escrow just boils down to having more trust in a well-known, positive trusted, long time member than in a newbie offering a potential-scam deal... Sure, the newbie *can* be legit and the well-known, postitive trusted, long time member *can* be pulling a long con, but the odds of the situation being exactly the oposite are far greater. A well-known, positive trusted, long time member also has something to lose: he/she usually invested years into his account, building up his trust... Usually he/she won't throw away all this work to steal a couple hundred bucks worth of BTC...
|
|
|
|
Dear Mr. --snip--,
Your coins are completely safe.
We'll try to reverse this EOS transaction at the earliest convenience.
That's the second time i see you use OP's real first and last name... Are you sure he's fine with being doxxed on bitcointalk? I haven't investigated his claims (yet), but personally i would hate it if you would link my bitcointalk username with my real life name (even if i disclosed my real life name to you over facebook or some other social media system) |
|
|
|
Which coin did you clone (including the release)? I remember cloning litecoin a while ago to do some tests, and at that point, getblocktemplate never included any transactions... Using the cli "generate 1 1000000" resulted in blocks including transactions from the mempool tough... In order to find out what's happening, it would be usefull if we knew which coin you forked, when you created the fork, how you configured your node, and how you are mining... the command yourcoin.cli getblocktemplate
might be a nice place to start (depending on which method you're using to mine) |
|
|
|
|
Show Posts
