Collusion between two parties is impossible, as all three are required to decrypt the seed.
Not necessarily. A collusion between the person having access to the will and therefore the decryption key, together with one of those two parties, will result in information leakage. And this leakage might be enough to bruteforce the seed. A 3 out of 3 secret sharing is not vulnerable to that. A multisig together with a secret sharing scheme indeed seems pointless. |
|
|
|
In the german section, there are two topics (from sportsbet and bitcasino) which offer merits as a prize for correct betting on soccer games. Merits are intended to express the appreciation of a good / worthy post. Giving them out as a prize seems.. odd.. to say at least. What is the general consensus regarding such behavior? What is your personal opinion? |
|
|
|
How can I get rid of every single installation I have made with bitcoin core on ubuntu? On windows I could simply go on %AppData% and remove the "Bitcoin".
You can not get rid of your installation by just deleting files in the AppData folder. Removing everything from an installation is way harder to achieve on windows than on linux. But.. how did we go to "Compiling and finding the executable works" to "Nothing is here" ? You had it compiled already, what did you do in the meantime?
No... bitcoind is the Bitcoin Core daemon... basically the "server" component that runs in the background. I asked because I wanted to know if the rest of it had actually compiled properly. "bitcoind" seems to have been built "OK", so if "bitcoin-qt" is not being output in the "src" folder along with "bitcoind" and "bitcoin-cli", then it would appear that your compile didn't actually work properly (unless you told it to build without the GUI... Did you use --without-gui with "configure"?  ) The file actually is the compiled daemon. And the compiled file bitcoin-qt is located in src/qt/OP already was able to find and execute(?) that file. |
|
|
|
Well, always good to have a few options in store to have something to choose from.
Over complicating things rarely has a positive effect. Mine which is composition of secret-sharing-scheme(SSS) and multisig wallet allows to mitigate some of numerous "if" the bare SSS couldn't cope with.
Which "if's" are you referring to ? Where is the vulnerability when using a secret sharing scheme in comparison to using that scheme together with multisig? However as it was pointed out by HCP even mine (not to mention bare SSS) would remained powerless against the specific cases that still possible due to the human nature.
If i am not mistaken, that's the reason why the secrets are divided into 2 groups which both include a human (prone to irrational thinking) and a bank safety deposit box. Whether who gains access to that under which conditions is key here. |
|
|
|
After reading this post I edited my previous post a bit. It makes sense when considering the risk of handling the private keys but in this case Coinbase eventually moved the BCH which means they already exploited the addresses to get the BCH from there.
+1 Respect for Royse777 who gets that they took the Bitcoin cash. If the Coins would of stayed in that address than I would of never reopened the case. If it's not a scam it's theft. Changed the topic from scam to theft. I agree that seeing the BCH got accessed, but not refunded to you seems unethical. But it definitely is not theft. You send them the coins yourself. And you are not obliged to receive them credited, since you sent them to a wrong address. You can hope for them to show their goodwill. But you can't force them. Additionally, just because the funds moved, it doesn't mean that a person accessed them. It is very well imaginable that this happened automatically without intervention from any human. However, refunding should be relatively easy in that case. That's definitely not how a company should act. But it is not illegal, and neither scam nor a theft. + If it's not company policy and It was a single employee he would likely get fired from Coinbase.
I doubt "a single employee" has access to the private keys. |
|
|
|
What happened::
Sent Bitcoincash to Coinbase Bitcoin address
So.. you made the mistake. You did not get scammed. You are the only one responsible for that. They might help you out of goodwill, but they definitely aren't obliged to do so. Te fund is easily recoverable if they want.
No, it isn't. It might be easy for you and me. But it definitely isn't for such a company. Well.. it is possible, but it has its price. There are strict security measurements. Not every person working for their support can access the private keys. It is absolutely understandable that most of it is automated and only a handful of people have access to the funds (probably multisig only). To be honestly, 2.5k$ might even not be worth their time required for that, depending on how many people are required and the security measurements (physical access, etc.) there. A lot of exchanges do that, yes. At least above a specific amount and for a fee. But that is absolutely out of goodwill and you have no right to request that. |
|
|
|
Such a set up is more secure than a hardware wallet.
But also less convenient. Having a seed from which the private key of a vanity address is derived, definitely has its charm. Obviously the time it would take to find a seed which has the vanity address in the first few derived keys, is much higher. But it might be worth it under some specific circumstances (e.g. the prefix of the vanity address doesn't have to be too long and mobility is important). |
|
|
|
|
Using mycelium without an HD wallet is an option too.
You could just create a wallet with a single private key and therefore a single address.
I don't know what your specific use case is, but this way you can have your signed message and always use the same address (as change address too).
|
|
|
|
|
Wer garantiert in dem Marktplatz, dass die Gutscheine / Geschenkkarten nicht illegal erworben worden sind (i.e. Kreditkartenbetrug etc.) ?
So wie ich das sehe, ist es ja nur ein Marktplatz der Käufer und Verkäufer zusammenbringt?
Somit also "Ermittlungsverfahren wegen Amazongutscheine v2" incoming ?
|
|
|
|
Ok, so i read the article and the statement from samourai. The two reasons why the vulnerability is critical (according to samourai) are: When a mixed output is remixed, these vulnerabilities break the ZeroLink guarantee for the previous mix, cancelling its benefits.
and These vulnerabilities break a core assumption of mixing, with each remix effectively canceling out the privacy gains of the previous mix.
If this is based on the assumption that the attacker has to know every UTXO in the wallet, there is no privacy to begin with. Further, they only reference on multiple mixing events. So the coinjoin itself is not "vulnerable", they claim that multiple coinjoins have the same effect than one coinjoin. To me, this seems just like the regular war between samourai and wasabi. The privacy is not broken, the coinjoins are not useless. Assuming that every UTXO of a user is known before coinjoining and also assuming that all UTXO's are enqued into a coinjoin is a pretty strong assumption to say at least. And even then, it is not like there is a vulnerability which de-anonymizes people. |
|
|
|
I guess if you've linked an IP to 1 address and then do this dust attack and link new addresses to that original address then you link the IP to all addresses...which I guess makes it easier to trace IPs?
Sure, if you already know an IP address associated to a bitcoin address, linking the same IP to other addresses happens automatically when you link different BTC addresses together. But finding out an IP address itself is not made easier with the dust attack. And that's somewhat the statement from the article you have linked. |
|
|
|
Besides the mine solves his concern of possible collusion between heirs. Sure OP can figure out his own way.
This problem already is being solved by the secret sharing scheme. That's not exactly true... It wouldn't need to be 3-of-6. If the OP was using Electrum, they could create a 3-of-3 MultiSig wallet... using 3 seeds... instead of using 1 seed + 2 pubkeys. That way, their copy of the wallet would have all the private keys needed to be able to create/send transactions. It would be akin to having a "disabled" 2FA wallet. OP could then give 1 seed to TrustedPersonA, 1 seed to TrustedPersonB and have 1 seed in Will. On death, the parties can then use the 3 seeds to recreate the wallet. In the meantime, the OP could use the wallet as they wanted for everyday use... it's still an HD wallet, so OP would get new addresses etc. And wouldn't look any different to any other P2SH type wallet really. Granted, the OP would need to keep backups of all 3 seeds, but that's not really any more difficult than keeping a backup of 1 seed from a "standard" wallet... you're effectively just storing 36 words instead of 12  That's what i actually was referring to with keeping a backup of all 3 shares. It is either OP has access to the 3 shares being distributed or 3 out of 6 shares if each share has to be individual. But somehow, i only was thinking about a single multisig address. Therefore the statement regarding the privacy. With a multisig wallet, the privacy obviously is not affected. |
|
|
|
|
Leute.. lest den OP mal genau.
Er bietet BTC und sucht Paypal/Überweisung.
@OP hier sind immer alle etwas aufgeschreckt wenn es heißt BTC <-> Paypal, da damit oft betrogen wird.
Daher an dich auch mal eine Warnung, akzeptiere kein Paypal von neuen oder nicht vertrauenswürdigen Mitgliedern.
|
|
|
|
This is the executable: So, either enter the directory ~/bitcoin-master/src/qt/ and enter: or run the following from your home directory: ./bitcoin-master/src/qt/bitcoin-qt
P.s. You are almost there!  |
|
|
|
They don't necessarily have an extension. The extension is just part of the filename. The file is named bitcoin-qt. To run it, enter: It might be the case, that the file is not marked as executable. In that case you first need to run: sudo chmod 744 bitcoin-qt
If it says, the file can not be found, run the following in the bitcoin-master directory: find . -type f -iname "bitcoin-qt*"
This should give you the location of the file. |
|
|
|
|
Yes, you are done.
make finished without errors. The binaries should be in your directory where you executed the command. In your case, that is: ~/bitcoin-master/ ~/bitcoin-master/src/
The output actually does not mean that "all" files are in doc/man.
|
|
|
|
Say you have 3 heirs to whom you trust. Create 3-of-3 multisyg wallet (in fact you should create 3 wallets with 3 MPK, and the final multisig will be 4th) to authorize transaction and using any SSS split the multisig wallet's SEED into 3 parts, any 2 of which capable to restore SEED for multisig. Hand over to every heir the full SEED for his/her wallet and his/her part of the split SEED relevant to multisig wallet. If even 2 of 3 heirs will plot to steal the money for themselves they can’t do it without 3rd signing wallet.
This would result in the circumstance that the BTC always need to be in the multisig wallet. For OP to actually use the wallet he either needs 1) a "backup" of the private keys everyone has to actually access the funds or 2) a 3 out of 6 multisig with him having 3 keys. Both is extremely impractical because he basically just has a single address to use. The previously mentioned approaches are better in terms of privacy. OP can use as many addresses as he wants without affecting the security of the backup mechanism or his privacy when transacting. I see downsides of your approach, but don't see any upside. |
|
|
|
This is what I get on ./configure
I tried the --with-incompatible-bdb but it doesn't seem to do anything.
--with-incompatible-bdb is a paremeter which needs to be passed to configure. It is not a command on its own. If you want to use that parameter, you need to execute: ./configure --with-incompatible-bdb
|
|
|
|
|
I guess you are talking about the transaction id?
Inside of the History tab, click on the transaction you want the id from -> The top field shows you the TX ID.
If that is not what you are looking for, what exactly are you looking for (or for what reason)?
|
|
|
|
|
What features does your wallet offer which is not present in the 100 other mobile wallets?
Which BIP's are you using?
Do you integrate CoinJoin? Reusable payment codes?
Do you use block filters? How is the transaction and balance information retrieved?
Anything which makes it worth looking at your wallet?
|
|
|
|
|
Show Posts
