One solution would be to switch to decentralized approaches, such as JoinMarket. After trying literally every service for this purpose (except the wasabi ones), I can safely agree that JoinMarket is my favorite one. I use others too, of course, but JoinMarket is the most decentralised one. AFAIK there's still no user-friendly interface which can rival Wasabi or Samourai wallet.
It comes with a fancy UI: Jam. Here is the installation guide for multiple node implementations: https://jamdocs.org/software/installation/If you think about it from a technical perspective, JoinMarket needs a backend implementation which is here: https://github.com/JoinMarket-Org/joinmarket-clientserver and a UI implementation which is here: https://github.com/joinmarket-webui/jamYes, it's not the easiest approach. Yes, it requires manual work. But it is worth it. |
|
|
|
|
It's been mentioned many times already but in general we need:
1. demand increase, more people get interested in bitcoin
2. supply decrease, therefore more difficult to find bitcoin
(2) is guarranteed to happen by the network rules
(1) is what we can focus on, introducing new people to bitcoin
There is no need to overcomplicate things, trying to read patterns, technical analysis etc.
Fundamentally speaking, (1) & (2) will lead to price increase.
|
|
|
|
|
Hello, I suggest you take a look into the service in my signature. It's the easiest way in my opinion. (edit: LoyceV said the same thing above, just noticed it)
If you are willing to share more info in regards to the trade you want to make, you could swap some BTC to XMR with someone here in the forum. I am also willing to consider this trade if you want.
|
|
|
|
DAY 8:{
"chain": "main",
"blocks": 825867,
"headers": 825867,
"bestblockhash": "0000000000000000000251f3f958e2992353dd50877c6cfb8a750a73ea948031",
"difficulty": 73197634206448.34,
"time": 1705303460,
"mediantime": 1705298015,
"verificationprogress": 0.9999987072597638,
"initialblockdownload": false,
"chainwork": "000000000000000000000000000000000000000065a824d15f40934c58397c0c",
"size_on_disk": 614712250513,
"pruned": false,
"warnings": ""
}
|
|
|
|
$ sudo ss -tulpn | grep tor | grep LISTEN
tcp LISTEN 1 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=39059,fd=6))
tcp LISTEN 0 4096 127.0.0.1:9051 0.0.0.0:* users:(("tor",pid=39059,fd=7)) for me the output looks like this: tcp LISTEN 0 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=23066,fd=6))
tcp LISTEN 0 4096 127.0.0.1:9051 0.0.0.0:* users:(("tor",pid=23066,fd=7))
The "1" in port 9050 means that there is 1 byte on the Recv-Q (receiving queue) waiting to be read. It's a rather curious number to be honest. Is it constantly "1" or have you noticed it going higher? I suggest you run sudo ss -tulpn to see all the ports. Are there any other ports that have Recv-Q higher than 0? Perhaps port 8333? |
|
|
|
Does bitcoin-cli getnetworkinfo show you are reachable by the onion network? Do you want to try if we can explicitly add a node via the addnode command? Are these options uncommented in your /etc/tor/torrc file? ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1
Can you run sudo ss -tulpn | grep tor | grep LISTEN to see if the tor service is listening at the ports 9050, 9051? |
|
|
|
You can verify yourself that this isn't copied-pasted from Raspibolt. For example, Raspibolt does bind to 127.0.0.1. I remember I had commented that, because it was producing issues with Bisq.
Correct, I have removed this line too. Yes. Here's my bitcoin.conf:
The differences with mine are: 1. I don't use onlynet=onion 2. I use v2transport=1 3. I use rpcbind and rpcallowip as explained in this tutorial: https://sparrowwallet.com/docs/connect-node.htmlCould it be firewall rules? I use ufw. Is your 8333 port opened? I see you say nothing blocks it, but can you verify using sudo ufw status? Can you please run bitcoin-cli getconnectioncount and then bitcoin-cli getpeerinfo? |
|
|
|
|
Usually the answer is simpler than it looks like. If you followed step by step Raspibolt's instructions, you shouldn't have these issues.
I tried connecting to your node and it didn't work, so let's try to find what the differences are between raspibolt's instructions and your node. The answer must be there.
Is your node onlynet=onion?
|
|
|
|
So, I was curious to know what methods were used by Satoshi, Hal Finney and the first participants? Can anyone share links about?
I am sure Satoshi and Hal knew ways to generate valid bitcoin key-pairs without using Bitcoin's software. They were both skilled professionals in cryptography. You can definetely generate the key-pairs without ever touching any bitcoin related software. I doubt they have done it though, because Bitcoin core is Satoshi's invention and it uses these techniques specifically. Today I read some reports from users with problems related to Electrum on Tails.
Tails is just an OS that does this: Tails always starts from the same clean state and everything you do disappears automatically when you shut down Tails
Electrum is a just a piece of software, developed in 2011. Electrum uses (as far as I know) os.urandom() to generate entropy and combines it with some other input sources (user inputs, time etc.). You can even see the main dev talking about it back in 2013 here on this forum: https://bitcointalk.org/index.php?topic=167276.msg1746905#msg1746905My questions to you are: 1. how can Electrum face issues specifically on Tails OS? 2. where did you read these reports? You know how people behave usually, writting whatever they want. Don't trust everything you read. However, if indeed you have spotted a problem regarding Electrum, let us know and we can inform the devs on github. It's fully open-source! |
|
|
|
Another thing I noticed in the release notes is that you can now put your payment requests to never expire. That's not bad because we sometimes get questions from newbies who believe their bitcoin addresses have expired and they are asking if the addresses are still valid and can be used. A never expiring payment invoice might minimize that.
You must be referring to this: * QML GUI (Android):
- new: allow never expiring payment requests (#8631)
Is it for LN invoices or for on-chain payment requests? I don't use electrum for android, that's why I ask. |
|
|
|
DAY 7:{
"chain": "main",
"blocks": 825744,
"headers": 825744,
"bestblockhash": "0000000000000000000058f2d949be5b6d75e4bdadc63b7e4d237653c55a436b",
"difficulty": 73197634206448.34,
"time": 1705221913,
"mediantime": 1705217709,
"verificationprogress": 0.9999968387607164,
"initialblockdownload": false,
"chainwork": "00000000000000000000000000000000000000006588283b277a0a0b617f8529",
"size_on_disk": 614468712878,
"pruned": false,
"warnings": ""
}
|
|
|
|
Does anyone know what this means? - remove SSL options from config
I don't think any of the changes interest me personally, so perhaps I will delay upgrading because of laziness.  Looks like a solid release though, with small but important features and fixes. |
|
|
|
DAY 6:{
"chain": "main",
"blocks": 825603,
"headers": 825603,
"bestblockhash": "000000000000000000037a262221634ffc442bc37c7c160358ec14e2225bba9f",
"difficulty": 73197634206448.34,
"time": 1705136961,
"mediantime": 1705134951,
"verificationprogress": 0.9999994427774004,
"initialblockdownload": false,
"chainwork": "000000000000000000000000000000000000000065637d5083a2efd3a452ed44",
"size_on_disk": 614190288502,
"pruned": false,
"warnings": ""
}
|
|
|
|
<snip>
I read the mail on the mailing list but there is one thing I haven't figured out. The idea of versioning, why do you think it is very important? I saw the concerns here: BIP39 seed phrases do not include a version number. This means that software should always know how to generate keys and addresses. BIP43 suggests that wallet software will try various existing derivation schemes within the BIP32 framework. This is extremely inefficient and rests on the assumption that future wallets will support all previously accepted derivation methods. If, in the future, a wallet developer decides not to implement a particular derivation method because it is deprecated, then the software will not be able to detect that the corresponding seed phrases are not supported, and it will return an empty wallet instead. This threatens users funds.
And I also saw gmaxwell commenting in 2017 that because of the lack of versioning he voted against using the BIP39. Since I am not so experienced, could you number 2-3 possible shortcomings of not having a versioning system, apart from the one mentioned in the quoted text above? |
|
|
|
First of all, thanks for your effort. I have a few questions as well: Question 1: You suggest that VF is a 32-bit field that is concatenated with the initial entropy. I assume something like this: ENT = 0010101...110 (128 bits long)
VF = 00001...101 (32 bits long).
I am not sure whether the VF will be appended or prepended to the entropy. Because you said "prepending" but the quote below looks like the input to the hash function will be ENT + VF, not VF + ENT. A checksum is generated following the BIP39 method: taking the first (ENT + VF ) / 32 bits of the SHA256 hash of the combined entropy (initial entropy plus the 32-bit version field). This checksum is then appended to the combined entropy.
Question 2: The VF is split in 2 parts where: part A = arbitrary bits (24 bits long)
part B = the version 00001101 (8 bits long).
So in part A, we can include any data we want? Because it looks like this adds 24 bits of "protection" against malicious activities. Isn't it? Supposing the 8 bits have a standard set of values, the total "protection" of the seed phrase will be: 128 bits of entropy + 24 arbitrary bits + 8 version bits (the latter will be somewhat standard) Question 3:Using a passphrase on top of that, will it work symmetrically to the existing BIP39 pattern? |
|
|
|
|
If I had made a guess it would have been $55k so I would have been far apart.
Congratulations to all the participant and of course to GazetaBitcoin and icopress.
Lastly, farewell light_warrior!
|
|
|
|
DAY 5:{
"chain": "main",
"blocks": 825485,
"headers": 825485,
"bestblockhash": "000000000000000000004313185be476ec79d0fb8129c6cee870fcd81efaf7a8",
"difficulty": 73197634206448.34,
"time": 1705077702,
"mediantime": 1705075984,
"verificationprogress": 0.9999965683992686,
"initialblockdownload": false,
"chainwork": "00000000000000000000000000000000000000006544cd98dba81d101d9c5bfe",
"size_on_disk": 613966779402,
"pruned": false,
"warnings": ""
}
|
|
|
|
ETF users don't need on-chain fees  I never said they need them  I never said you said that But you never said that I said that you said that. Never mind, I'm going to get a drink You guys need a break Seriously though, I doubt fees will increase because of the ETFs. They will inevitably increase as long as people use bitcoin more and more. (and yes dkbit98 said this already ) |
|
|
|
DAY 4:{
"chain": "main",
"blocks": 825333,
"headers": 825333,
"bestblockhash": "00000000000000000001effacfe911621c225879148c276000f753b78d68503b",
"difficulty": 73197634206448.34,
"time": 1704990211,
"mediantime": 1704989116,
"verificationprogress": 0.9999995585458187,
"initialblockdownload": false,
"chainwork": "0000000000000000000000000000000000000000651d465e2eaa715e039b7e26",
"size_on_disk": 613680624442,
"pruned": false,
"warnings": ""
}
|
|
|
|
For now 24h XMR volume seems to be fine on eXch: 12k XMR  I take responsibility for some of them |
|
|
|
|
Show Posts
