|
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) |
|
|
|
--snip--
For example, here are 5 pages for the word raspberry.
And how many more questions on the topic of coins how to make a wallet or configure it correctly, I'm sure that the section will be very popular among users.
5 pages isn't a lot, especially since your screenshot shows search results starting 7 years ago... 5 pages in 7 years, including for-sale threads... Don't get me wrong, i'm defenately not against your idear if there's a real demand for such a subforum, but maybe Theymos would want to avoid another subforum that's barely used? Anyways, it's Theymos's call, but if you're really serious, i'd try to make a better case (just my 2 satoshi's tough) |
|
|
|
Its quite strange to have a talk about something you have no idea about. Vanitygen goes up to 250 million keys per second with an old gpu card, so I dont understand why you spend such a long post explaining something that is not accurate and misleading, then get cudos from "friends" who cheer your errors.
If you would have taken the time to read the complete post, it would have had to be obvious for you the only inaccurate part is the fact that I have found no good oclvanitygen gpu benchmarks, so I had to work with data from a Reddit post... I clearly indicated this, it was rather hard to mis IMHO. In my post, I already used 230.000.000 keys per second in my calculation.. now you say 250.000.000... don't get worked up about the difference, it's bad for your heart health... Even if a new gpu would generate a tenfold of this, it wouldn't matter: the conclusion of my initial post stays exactly the same.. 16 Septen-decillion years or 1.6 Septen-decillion years for a 0.01 percent chance, the sun will probably die in 7 billion years, so neither of us will be around in 1,6 septen-decillion years anyways... Why would you say my post is misleading? Would you say you'll be able to bruteforce a private key within a single lifetime? My address is in my profile, if you pm me my full private key (preferably pgp encrypted with my keybase public key), I'll immediately apologize to you and the full community, and let you pick my personal text for a full year (as long as the text is not illegal or gets me banned) I wonder if you are trying to draw attention to your(?) business in your signature by acting rather condescending and focussing on the wrong things ? |
|
|
|
I have 28 Ethereum, where can that get me mate?
The current exchange rate is 1 BTC =~ 48 ETH 28 ETH =~ 0.58 BTCyou'll need this 0.58 BTC to be 120% of the loaned amount + intrest... This means you'll need to pay back 0.48 BTCSo... with 28 ETH, you should be able to get a loan of 0.4 BTC, repaying 0.48 BTC... I think that should be do-able for several lenders. Do realise they'll probably want to use a forum escrow to hold the ETH, so the escrow fee should also be deducted from the 0.4 BTCI take no responsability for any calculation errors i could have made! Good luck  |
|
|
|
Bitcoin cash🙄
And i can other Ethereum as a collateral
This changes everything... You'll need about 30 BCH or 44 ETH as collateral in order to cover a 0.5 BTC loan with a 0.75 BTC return (120% of 0.75 BTC in BCH and/or ETH)... If you have these amounts of BCH or ETH , and you allow a trusted forum escrow to hold the collateral, i'm pretty sure everybody will jump in to take your deal.... good luck |
|
|
|
3NzYDmQCwvXPnzw1q97bk9SnRDZvVeEEyY
Could i have yours for repayment please?
I think efialtis forgot the sarcasm tag... You're requesting about $5000 without even offering any collateral or having *any* history at all in this community (altough, even if you're a highly trusted member this is not going to happen, nobody is going to lend anybody $5000 without valid collateral)... That's just not going to happen |
|
|
|
Theoretically it will never happen. You can try a tool called vanitygen and use the prefix 1D or whatever you want, it will take quite some time.
"Quite some time" is an understatement. There's a lack of benchmark results for oclvanitygen (the optimized, GPU version of vanitygen)... But one of the results i found was this one: https://www.reddit.com/r/Bitcoin/comments/1sntt7/48_hours_of_gpu_vanitygen_and_4_trillion/This user claims to have generated 4 000 000 000 000 addresses in 24 hours using "a" GPU. That's about 23.148.148 keys per second. That's feasible, given that i've found "other" vanitygen (not oclvanitygen) benchmarks in the 5 Mk/s range, so throwing a gpu in the mix could result in a 23 Mk/s result. Let's, for the sake of argument say that this user's setup was using an old GPU and inefficient coding, and a top-shelve GPU with decent address mining software could churn out a tenfold (230.000.000 keys per second). Let's say you have a theoretical farm of 100 of these GPU's, churning out 23.000.000.000 keys per second... They'll need to test 2^256 keys... This means your farm will need 2^256 /23.000.000.000 seconds to scan the complete keyspace. If execute this calculation and convert the results from seconds to years, you'll end up with a total scantime of 159641002742643597687626818499610000000000000000000000000000 years to scan the complete keyspace. If you want to scan 0.01% of the total keyspace (thus have 0.01% chance of finding the exact private key whose public key hash was funded), you'll need 15964100274264359768762681849961000000000000000000000000 years... For people that are not used to read such large numbers, i've looked up the proper naming convention... This allows me to say: If you have 100 High performing, latest gen GPU's and good drivers and software, you'll need to run your farm for 16 Septen-decillion years in order to have a 0.01% (that's percent, that's 0.01 chance in 100) to find a private key that belongs to one specific address.. |
|
|
|
Well it happened in about a week to month ago.
In my country there was some media coverage about these scams a couple weeks ago... Apparently the amount of scams have reached the threshold needed to attract the attention of the press and the police now. If i read your story, it's the exact modus operandi described in the media, so i can pretty much guarantee your friend was scammed. Like it's been suggested before: stop sending them money, go to the police, consider your funds to be lost. BTW: these scams have NOTHING to do with the actual crypto community... Scammers just pick whatever technology is "hot" in the media right now and use buzzwords from this technology to scam unknowing victims. If bitcoin wouldn't exist they'd find an other angle to scam people using more or less the same methods they're using right now. It's a shame these dirtbags are dragging our community trough the mud, ruining our reputation because we get linked to them... They're just thieves that use our community fame to steal from (mostly) older, non-tech-savvy people. |
|
|
|
--snip-- what are the chances of getting this address if keep you generating only addresses starting with 1D , and how many years you need  You can't "just" generate private keys that result in an address that starts with "1D". The private key is used to generate the public key. The public key is hashed to generate the address. Both steps are one-directional, they cannot be reversed. You can't say: my address has to start with "1D", so i'll reverse the hash function to find all possible public keys, nor can you start with a public key and calculate the private key... The only thing you can do is scan the complete private key space, calculate the public keys belonging to the private keys, then hash the public keys and filter out addresses starting with "1D"... This would take even more time than scanning the complete private key keyspace, calculating the public keys, hashing the public key and NOT filtering out addresses starting with "1D". Do realise that scanning the complete keyspace is ludicrous, even if you pool all computers in existence together, the earth will have ceased to exist before you can scan a significant part of the keyspace |
|
|
|
It's a bug in blockchain.com's algorithm... blockchain.com is just a block explorer... They just run a couple of nodes and parse the blocks and unconfirmed transactions they receive. If somebody messed up the parsing code, you end up with things like negative balances. This bug has no significance in the real world, blockchain.com is not the owner of bitcoin, it's just a private company that builds things like an online wallet and a block explorer. Most other blockexplorers are probably fine: https://blockchair.com/bitcoin/address/1Fr8qEa7vcwJikeW9q6thaYZPacGY5CQAb |
|
|
|
|
Some nice advice has been given, but i'd like to put some emphasis on part of BitCryptex and jackg's initial posts... They are correct, but it seems their posts have been overlooked...
Running a full node isn't necessary if you don't want to... If you have problems with the time it takes to do a full sync, or the amount of data you need to store, start looking at an SPV wallet.
An SPV wallet only downloads the block headers, not the complete blocks. A "full sync" of all headers happens in a matter of minutes and only uses a couple Mb on disk, and i find SPV wallets sufficient for most day-to-day task.
Let's be honest: it's a good thing for the network if a lot of people run full nodes, it's good for an enduser to verify all blocks and all transactions, but it isn't absolutely necessary for everybody to run such a full node if they are only going to perform enduser tasks. If we have several thousand full nodes, endusers can use SPV wallets without significant impact on the network's security (imho).
Granted, if you use an SPV wallet, you do rely on other nodes and you give away a small part of your privacy... But security-wise SPV wallets seem to be fine.
If you worry so much about synctime and diskusage, download and verify the latest version of electrum, or buy a ledger or trezor (both spv hardware wallets). By using a HW wallet, you'll even add an extra layer of security....
|
|
|
|
|
Show Posts
