AFAIK, ethOS comes as a disk image, so you should be able to write it to your SSD... Untested by me tough, just based on what i've read about this OS in the past

This topic actually belongs in the altcoin mining subforum.

That being said, your initial description of the problem isn't really informative:


Could you at least tell me/us:

• Which mining software you're using (you already told us you're mining ravencoin)
• Which distro you're running and how you set everything up
• If there are error messages being shown
• If there's anything in the syslog/debug log
• Wether or not you were running in daemon mode, or maybe using screen over an ssh connection... Or were you working straight from the console.
• Did you OS freeze, or just the miner
• Which steps you already took in order to debug the problem
• Maybe even some profit calculations... I don't know if it's worth a lot of time to investigate if you estimate to make a couple cents a year vs several thousand $?

I don't mean to nitpick, but this solution wouldn't change a thing... Even if i only entered one receiving address, the address would still be funded with 2 new unspent outputs. If i wanted to spend those 2 unspent outputs, fee-wise, it wouldn't matter if they were funding 2 distinct addresses or one address, the transaction size would be roughly the same for both situations...

The transaction size is based on the number and type (P2PKH, P2SH,...) of inputs the number and type of outputs... Not on the address that was funded

EDIT: after re-reading my post, i realise i sound a bit harsh... But the way i see it: you payed me a couple bucks to get a review you can actually use to improve your service... Sure i could have said: "everything looks find, your mixer is perfect", but if i did such a thing, you would have payed me to kiss your *ss . Instead, i decided to give a review focussing on the things you NEED to fix, so that the couple bucks you spend on my review will allow you to improve your system... There are many positive points about your mixer, but since everybody can see those, i didn't feel a need to repeat them once again...

On friday, i received some test funds, but since i payed a suboptimal fee (slightly less than the recommanded fee), it took the transaction a while to confirm. Today (monday), i noticed i had received the mixed coins...

I have discussed my security concerns in a previous post, especially the MITM by using cloudflare's ssl certificates and the includes of google tracking codes worried me...
That being said, i found the testuse of your mixer pretty straightforeward, i could easily navigate your menu's and i was pleasantly supprised by getting a letter of guarantee signed by you (and not [banned mixer]).

The one thing i noticed:
Including fees, i have spent 0.001962 to make a 0.0015 BTC transaction.
Your exact value and fee calculator told me that a 0.0015 BTC deposit would result in a 0.00128 withdrawal.
When i combine the output values of the two transactions funding my withdrawal address, i get 0.0012795... I know, it's only 0.0000005 BTC (50 satoshi's) less than you promised, but since you already take quite a hefty fee, i think that you should make sure the calculated output value matches the actual output value.... On top of this, splitting the output into two unspent outputs increases the fee i'll have to use to spend both by about 0.0001 BTC compared to spending a single unspent output (at current feerate).
This means that, after spending 0.001962, i'll get the equivalent of 0.0011795 BTC in clean, spendable funds... Thats ~40% less... Offcourse, the main reason for this fee is the fact that you use a percentage based AND fixed fee, and the mining fee is currently pretty high compared to a low input value (and i used 3 inputs for my deposit tx, to it was a tiny bit larger than a "default" tx)... I'm sure the fee is a lot less if you mix bigger values at a time the network fees are more reasonable... But still, ~40%...

I know why you don't allow people to chose the output timeframe, nor the number of outputs, nor the size of the outputs, nor the exact fee... However, i like to feel in controll... Personally i'd like to have some kind of "expert - i know what i'm doing" menu that allowed to to chose the size and number of outputs, the feesize and the delay.

Ending on a (very) positive note: i traced the outputs funding my withdrawal addresses and ended up on a poloniex wallet for one of the outputs, and an unknown wallet holding ~80 BTC after  +1000 transactions... This means that your system is telling the truth and the funds are coming from a clean source.
This being said, it does look like you get a big unspent output from a "clean" source, and you keep re-using this unspent output to fund all mixing sessions...
It's like:

unspent output of 3 BTC from a clean source funding your address
unspent output of 3 BTC used to pay first client => 3 BTC in, 2.9 BTC to your change address, 0.1 BTC to your first client
unspent output of 2.9 BTC used to pay second client => 2.9 BTC in, 2.7 BTC to your change address, 0.2 BTC to your second client
unspent output of 2.7 BTC used to pay thirth client => 2.7 BTC in, 2.6 BTC to your change address, 0.1 BTC to your thirth client
unspent output of 2.6 BTC used to pay fourth client => 2.6 BTC in, 2.3 BTC to your change address, 0.3 BTC to your fourth client

The thing is: it will allow me to find other people that used your mixer, since i only have to follow the trace after my own mixing session. This is not a problem, as a matter of fact, it's pretty common to see this kind of behaviour amongst mixers, as a matter of fact, it's the same with chipmixer (if i initiate a mixing session and get my chips, i can now follow other people that used chipmixer).

As for now, i will not use [banned mixer] untill the security flaws have been fixed and you think about the exact fee calculation, but all in all, i'm impressed

Good luck!

Strange, You did tell me that i would get the 20th spot:



So you should already have my address

Sure... But:
step 1: if your computer is infected with a virus or a keylogger, you lose all your funds
step 1: since you now have a blockchain account, you run the risk falling for a phising scam
step 2: if qr-code-generator saves your query, they have your private key
step 2: if you visit a non-ssl version of the site, dozens of people will be able to capture your private key
step 3: downloading on itself isn't even safe... Nor is printing using a network printer

Do not generate a paper wallet from an online machine, do not generate a paper wallet using a web wallet.

Use an offline tool, stay offline, use bip38 encryption, never let your private key touch an online machine (don't even go offine directly after creating your key, reboot first) like the walktrough i initially posted on this very topic.
If you can't follow these logic steps, your paper wallet will LESS secure as the online wallet you used to generate your key in the first place... It would defeat the purpose of a paper wallet.

If you're afraid you'll lose your funds, make a paper wallet for the testnet first, fund it with testnet coins, sweep it with a testnet wallet...

One of the bitcoin slogans is "be your own bank"...
YOU should controll your OWN private keys... If you fall for a scam there is NO central bank you can complain to, there should be nobody controlling your keys but yourself.
There are a couple online wallets, but if you use them you are trusting them instead of yourself.

In your case, the only one you can actually blame is the scammer who took your money... You can (and should) go to the police, but you should realise they cannot give your money back and they can not force anybody to give you your money back... No central authority and confirmed transactions are virtually irreplaceable (unless you own billions of dollars worth of asic's)

Hi,

I haven't received the testing fee (yet), but i was a bit anxious, so i decided to analyse the site before actually using it. In order not to be influenced by previous posters, i decided not to read other reviews before making my own, as a result i might say things that have been said before.

All in all, i like the way it's designed, but i'd like to see several issues being fixed before i would even consider using the service for actual mixing:

• You're using cloudflare's SSL certificates... That's a big no-no for me (cloudflare acts as a man in the middle)
• You're importing scripts from google tag manager. This means google can log who's using your site
• A lot of javascript is being used... I haven't tested your tor mirror, but i like to disable javascript when using my tor browser
• 4 cookies are being set...
• HSTS is not enabled
• CSP header was not set
• The referer policy was not set
• X-Frame-Options header was not set
• X-XSS-Protection header was not set
• I see a _gat_UA-124028682-1 cookie... Google analytics? Really?

The issues on this list result in a companie (an US based one!!!) being able to see all unencrypted data that's being sent between your enduser and yourself, and a second company won't be able to see the actual data, but will still have access to all your customer's ip's, browser fingerprint, times, referrers, exit pages,...
Next to this, i'll need to enable javascript, so it'll be easyer to fingerprint my browser and there were no precautions for (amongst others) XSS.

Next to this, i personally think 4-5% fee is on the high side, and i see you're linking to the public key of [banned mixer], does this mean i'll get a letter of guarantee signed with [banned mixer]'s private key? This isn't a real problem, but me (a customer) would like to get a letter of guarantee signed by you ([banned mixer]), NOT by [banned mixer]

The rest of the review will follow once my slot has come up and i received the testing fee

BTW: don't take this list the wrong way, there's a lot on the list, but nothing that can't be fixed... I'd rather see you succeed that fail, so i'd rather see you fix the issues and do a lot of businnes

In 3.3.6, under preferences, under the tab "fees" there should be an option "edit fees manually". If you enable this option, you should be able to go as low as 1 sat/byte... However, you do have to realise electrum does not guarantee your tx will find it's way into a block within 240 blocks if you pay a x sat/byte fee. It's only an estimation based on the last couple of blocks, the fee (in sat/vbyte) and the size of the mempool.
If, by the time 240 more blocks have been found, the mempool gets flooded with loads of transactions paying higher fees (in sat/vbyte) than you, you'll have to wait longer... The shorter the estimated time, the higher the odds of your tx getting into a block within the estimated timeframe.

One last tip: if you start messing with the fees, it might be wise to enable rbf by default...

I don't have ledger live installed on my workpc, so i cannot give you a walktrough...

However, if you connect your ledger to electrum and enable the address-tab you should see all addresses (funded, previously funded and unfunded up to the gap limit).

This being said, as a normal user, there is hardly any usecase for this... There are only a very little amount of circumstances where you (as an enduser) would need to find out how to find the list of change addresses. As long as your balance is ok, and you don't see outgoing transactions you didn't make, everything should be fine

My best guess, without knowing your transaction id or address you funded, would be that your ledger just created a change address. This is the way the protocol works.

You probably had a 0.0574 unspent output funding your address, you used this output as an input to create a new transaction. 0.0004 funded your coinomi wallet, 0.057 funded a change address generated by your hardware wallet.

You do know coinomi has had several vulnerability's in the past, right? (unrelated to this topic tough)

Well... using this info you should be able to calculate the size of the witness data (but like i said before, knowing this size isn't actually important, as long as you know the vsize.

source:https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_size_calculations
source:https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Transaction_size_calculations

total transaction size = 372
virtual transaction size = 209

So... transaction weight : 209 * 4

(209 * 4) = (size of tx without witness data) * 3 + 372
(size of the witness data) = 372 -  (size of tx without witness data)

If i didn't make any errors... this should wean your base transaction would be ~154 bytes, the witness data would be ~218 bytes (core does round the vsize to the nearest integer, so the "actual" vsize is likely not exactly 209, so if you calculate the sizes you don't end up on a round integer)...

The main problem is that i don't know the transaction you're talking about, so it's not that easy to actually give you some advice... There's also the possibility you used a decoder that messed up.

Can you try http://chainquery.com/bitcoin-api/decoderawtransaction to decode the raw transaction?

In reality, it isn't even that important to know the size of the witness data... It's just important to get the vsize...

Since i don't know your actual transaction, i browsed my mempool and found a segwit transaction (not mine)

If you use chainquery to decode this transaction, you'll actually be able to see the witness data, the "actual" size and the vsize...

Well... I'm going to simplify even further here, so don't start looking into the actual theory and then come back to this thread to point out any inconsistencies i made

Basically, from the view of a legacy node, a segwit transaction is using an unspent output that can be spent by everybody as input. Since everybody can spend the unspent output used as an input for the tx, the witness data (containing the signature) isn't needed, but the transaction still has an input and an output section, and for a legacy node, the transaction is valid (it uses unspent outputs as an input and creates new outputs).

A "newer" node also receives the witness data (stored outside the first 1Mb), and knows that the unspent outputs used as an input for the transaction can't be spent by anybody... The "newer" nodes have the witness data, so they're able to actually check the signatures annd verify if the transaction is actually valid.

I can't really answer the last part of your question... Segwit is a soft fork, so normally there would be no pressure on old nodes to upgrade... However, nobody knows if there'll be a hard fork in the future that actually builds on (some of) the building blocks introduced by the segwit softfork... If such a hard fork would ever occur, the "legacy" nodes would probably have to upgrade if they wanted to stay part of the main chain.



Yes, you can... You can save the transaction from electrum, open it with a text editor and copy the hex data... Then use one of the many online tools to decode the transaction... You'll be shown the size and vsize... vsize = virtual size, it takes the segwit data into consideration.
Each byte that should find a place in the first 1 Mb counts for 4 vbytes, each byte outside the first 1Mb count for 1 vbyte

I agree with pooya87 but wanted to give a less technical explanation. It's less correct, and it contains some analogies, i sacrified technical correctness for simplicity.

The blocksize used to be limited to 1Mb since a very long time, with the introduction of segwit the blocksize suddenly became 4 Mb... But, since segwit is a soft fork, older nodes should still be able to receive 1 Mb blocks (strange stuff, isn't it ).

How is this solved? The "actual" transaction data contained in 1 block is still limited to 1Mb, so all the "important" data of both segwit and non-segwit transactions should still fit in this 1 Mb space. However, segwit introduced a smart "trick" (for lack of a better wording). It removed the witness data from the transaction. This witness data can be stored in the "extra" 3 Mb space, making the rest of the transaction that has to fit in the 1Mb block a lot smaller. Since the fee is calculated in satoshi/byte, it's logical that the smaller the portion of the transaction that has to fit into the 1Mb block, the lower the fee should be.

But, like pooya87 already said: there is no "segwit space", a big chunk of the segwit transaction still has to compete with both segwit and non segwit transactions to find a space in the 1Mb block... A segwit transaction just takes up less space in the 1Mb block because part of the transaction can actually be placed outside the 1Mb block.

"Newer" nodes receive the full 4Mb block (usually smaller), "legacy" nodes only receive the first 1 Mb containing all the important information of every transaction. A legacy node will receive less information about the segwit transaction, but since the rest of the network's non-legacy nodes received the full 4Mb block, the witness data is still known to the biggest part of the network.

Blockchain (the company) does NOT have the power to block wallets or return funds... This is not how bitcoin works.
The best blockchain can do is reimburse you with blockchain's money... But they won't do this unless maybe if you have a strong case that it was blockchain's fault you lost your funds due to a vulnerability on their end... Maybe they can technically block the attacker's ip from using their wallet, but the funds would still be lost.

Only a centralised exchange/wallet that does not give you access to your own private keys can roll back INTERNAL transactions (transactions between two wallets from the same centralised provider)

You have the developer reference here:
https://bitcoin.org/en/developer-reference

Or the git repo here:
https://github.com/bitcoin/

And even the complete sourcecode here:
https://github.com/bitcoin/bitcoin

Good luck!

the method "listunspent" returns an array of unspent outputs, for each output the txid, vout, address,.., amount,... will be returned. It's up to you to create a sum of all amounts for each address. You'll need the txid and vout in order to create a raw transaction btw...

There's also the method "getreceivedbyaddress"

The big difference between the two is that the first method (using listunspent) will return a lot of information you'll need when creating a new transaction (tx, vout, number of unspent outputs) but you'll have to calculate the sum yourself (but, in all fairness, if you don't know how to do this, you shouldn't be working on a project to begin with ), while on the other hand getreceivedbyaddress will give you a "simple" result... Just a value indicating the total amount in btc that was received by the address you queryd

yes... It can be done

In the gui => coin controll
In the cli (or json-rpc) => "listunspent" to see unspent outputs => "createrawtransaction" to create a transaction using these unspent outputs => "signrawtransaction" to sign the raw transaction => "sendrawtransaction" to broadcast the signed tx

You'll have to combine the cli sollution with "decoderawtransaction" to look at the vsize and "estimatesmartfee" to see which fee is appropriate at that time. Oh, and the "getrawchangeaddress" to create a new change address (don't overspend on fees by not sending the change to a change addy!!!)

Both sollutions (gui with coin controll and/or cli) would also allow you to send funds to multiple addresses (users) in one transaction, increasing the size of the transaction, but still saving on fees because 1 transaction combining many unspent outputs as input and generating many new unspent outputs as output is smaller than several transactions combining less unspent outputs as input and creating 1 (or 2) new outputs (don't forget the change address)

I've actually had a quite similar tought as the OP for a long time. In my country there's a time limit for each crime.
This is the wiki page (sorry, it's in dutch): https://nl.wikipedia.org/wiki/Verjaring

For example, a traffic violation can only be punished if it's brought before a court within 1 year after the crime has been committed. Other crimes carry an expiration period of 5, 10, 20,... years, but only crimes like commiting genocide don't carry an experiation period.
If this expiration time has passed, it can still be proven that a crime has been comitted, the person is still guilty, but the court finds that it's no longer a good idear to actually punish somebody for a crime they committed so long ago (given the fact that they didn't re-commit the crime afterwards).

In forum terms: it's Theymos's forum, he's the admin and by having an account on bitcointalk you'll have to follow his rules. That being said, i think we can still make an argument towards Theymos and maybe make him changes his mind.
I, for one, would like to see *some* crimes "expire". Not because i have an alt account that's being banned, but because i think banning people for things they did years ago will make good community members leave this forum, making it a worse place. If somebody commited 1 act of plagiarism 5 years ago, but never did anything wrong after this 1 act, while still making hundreds of helpfull posts, would it still be a good idear to punish him/her (even with a sigban)? Offcourse, if he plagiarised 5 years ago, and re-commited plagiarism 1 year ago, he can't be punished for the crime he comitted 5 years ago but he CAN be commited for the one 1 year ago.
I think, legally, it might also be a good idear to remove old, plagiarised posts by a red warning so no offending content can be found on bct, and an offender should still receive a public or private notice that what he did was, in fact, a crime, but he's not being punished because the crime expired....

Just my inner toughts here... Open for debate..