Got it, thanks.
I'll get started tonight. I'll uninstall the test version, download the core again now that version 27 is out, and start from scratch.
Extra time is fine. BTC ain't going away.
I'm glad to see people sticking around  By the way, if you run a daemon on the testnet, the data is stored in a testnet3 subfolder. Usually, there's no real need to uninstall and re-install to switch from testnet to mainnet. Usually it's sufficient to edit your bitcoin.conf (and restart your daemon) or stop your running daemon and start it without the testnet parameter. If you do this, you'll keep your testnet data and wallet (stored in a testnet3 subfolder), so if there's ever a need to start your daemon in testnet mode again, you won't have to re-sync everything. Personally, i try never to throw away a wallet.dat, but if you've never touched the main net, just erasing everything and restarting doesn't seem to be harmfull to me. |
|
|
|
|
you have to re-sync if you switch from the testnet to the main net i'm afraid.
ps: the amount of data inside the mainnet blockchain is a lot more than the amount of data in the blocks of the testnet chain aswell. If it took you several days to sync the testnet, it'll take a lot longer to sync the main net i'm afraid.
|
|
|
|
You should set TestNet's RPC connection port rather than MainNet's.
It's "18332"
Bingo! thanks! Now the larger question - is this node (testnet) any good? I want a real node to make real transactions rather than a "sandbox". Not sure what I clicked on while installing the core. Do I need to start over again and install it as "mainnet"? Depends on what you want to do... Do you want to learn about bitcoin in a safe way without any chance of losing "real" money, then yes, testnet is perfect... Testnet is an ideal tool for learning, experimenting, scripting,... If you actually want to transfer value, receive payments, make payments, invest,... you'll need to switch to the main net. It's basically in the name: testnet, tBTC (testnet BTC) is worthless, testnet can be reset at any time in the future and all your unspent outputs on the testnet will be gone... Don't buy tBTC, get it from a faucet and use it to learn how to use your wallet, create transactions, spend funds,... Once you're done learning and experimenting, switch to the main net. |
|
|
|
|
I would not trust this either... A cold call after losing your coins reeks of a scam being set up.
The mere sharing of an address does not sound harmful to me (unless looked at from a privacy perspective), but it could be a way to setup trust. It could be the first step into getting your brother send funds, share his private key or install some piece of malware on his system.
Personally, if it were my brother, i'd tell him to not entertain this cold caller. Transactions are irreversible, there is no way of just getting your funds back. The only way to get your funds back is when the scammer is (forced to) send your money back, and usually this means going trough legal channels. There probably are firms that help you get in touch with law enforcement and help you track scammers down, but those companies don't just cold call victims.
|
|
|
|
|
you could do this, sure... But if you have your node, your electrum server and your electrum client all running on the same home network (lan) or even on the same machine, you could potentially configure your node to only listen for P2P traffic on tor (by setting listenonion=1 and onlynet=onion in your bitcoin.conf) but still listen for json-rpc calls on your node's LAN network interface (rpcbind=0.0.0.0 and rpcallowip=192.168.1.0/24 in your bitcoin.conf... the allowip needs to be adjusted to your home subnet).
That way, you could configure your electrum server to connect to the rpc port on your node, using the credentials or cookie file, using the network interface inside your lan.
Afterward, you could connect you electrum client to your electrum server... You *might* not even want to use ssl for the client to electrum server connection, since all traffic stays within your home network (but for some reasons, you might want to chose an ssl setup nontheless).
If you run your node on a VPS somewhere on the internet, and your electrum server on an other vps, and your client on your home computer, privacy-wise it might be the best idear to setup your node for tor communication only, setup your electrum server to connect to your node over tor, and setup your client to connect to your electrum server over tor... Like the person you quoted already said: your isp might not be able to read the actual packages (if ssl is used), they'll still know you're exchanging packages with your electrum server...
|
|
|
|
--snip--
I'll try your container next (and I've never used containers before). CPUmining would be fun, I tried it before on testnet, but had to conclude it's impossible. If there's even a single ASIC mining on testnet4, I expect CPUmining to be futile already.
The mining container is ready, it works, but (like you suspected) somebody is already running one (or more) asic's on testnet4.... why... i really wonder why.... why would you run an asic on a network that's designed to test ... why won't you let others get some tBTC to play with... At least, if you're nuking the testnet, create a faucet where others can have some tBTC to test out their setups... If you need help with containers, let me know... But basically, if you trust what i've done, you could basically install docker and docker-compose on your system, make sure the docker daemon is running (on most linux distro's, a systemd service is created for you, you just need to enable and start it), then copy the content of the docker-compose.yml code block from this post ( https://bitcointalk.org/index.php?topic=5496494.msg64078200#msg64078200) into a local docker-compose.yml file, edit the paths, ports and passwords and execute "docker-compose up" (or "docker-compose up -d" to start in the background) If you don't trust what i've done (i don't blame you), you could copy the first code block in above post in a file called "Dockerfile" (you can check all steps), then run "docker build -t name_of_image:random_tag .". At this point, you'll have an image of your own in your local repo, and you can edit the image: tag in the docker-compose.yml file to point to your local image instead of mine. |
|
|
|
Hi LoyceV, Yup, you were right, you had to keep the top line, the bottom one is no longer needed. It might be best to just use the container, i have it running on a demo machine and it works just fine... But if you want to try to build it on your local machine, you're always welcome to shoot me a quick PM (local language is fine, doesn't have to be in English) I'm currently figuring out if i can build some kind of cpuminer in the same container and get it to work properly... cpumining might be long dead, it should still be feasible for testnet4. PS: thanks for pointing out the typo, i'll fix it right away |
|
|
|
I have tried to put a "mining" image together aswell: FROM ubuntu:22.04 AS miner
#start.sh sets proxy for apt, needed for my env
#COPY start.sh /usr/local/bin/
#RUN chmod +x /usr/local/bin/start.sh
#RUN /usr/local/bin/start.sh
RUN apt-get update \
&& apt-get install -y \
build-essential \
libssl-dev \
libgmp-dev \
libcurl4-openssl-dev \
libjansson-dev \
automake \
git \
zlib1g-dev \
&& rm -rf /var/lib/apt/lists/*
RUN git clone https://github.com/JayDDee/cpuminer-opt /cpuminer
WORKDIR /cpuminer
RUN ./build.sh
FROM ubuntu:22.04 AS builder
#start.sh sets proxy for apt, needed for my env
#COPY start.sh /usr/local/bin/
#RUN chmod +x /usr/local/bin/start.sh
#RUN /usr/local/bin/start.sh
#install all prereqs
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y tzdata && apt-get -y install git autoconf pkg-config libtool build-essential bsdmainutils libevent-dev libdb-dev libdb++-dev clang python3 libssl-dev libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev libminiupnpc-dev libzmq3-dev libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libsqlite3-dev ccache
#pull pr
RUN git clone https://github.com/bitcoin/bitcoin.git /bitcoin
WORKDIR /bitcoin
RUN git fetch origin pull/29775/head:pr-29775 && git checkout pr-29775
#compile
RUN ./autogen.sh
RUN ./configure --with-incompatible-bdb CC=clang CXX=clang++
RUN make -j "$(($(nproc) + 1))"
WORKDIR /bitcoin/src
RUN strip bitcoin-util && strip bitcoind && strip bitcoin-cli && strip bitcoin-tx && strip qt/bitcoin-qt
#multistage
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y libdb5.3++-dev libminiupnpc-dev libevent-dev libzmq3-dev libsqlite3-dev \
libjansson-dev libcurl4-openssl-dev
COPY --from=builder /bitcoin/src/bitcoin-util /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoin-cli /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoin-tx /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoind /usr/local/bin
COPY --from=builder /bitcoin/src/qt/bitcoin-qt /usr/local/bin
COPY --from=miner /cpuminer/cpuminer /usr/local/bin
you can build it yourself, or get if from dockerhub mocacinno/btc_testnet4:cpuminer if you use this docker-compose.yml to start: version: '3'
services:
bitcoind:
image: mocacinno/btc_testnet4:cpuminer
privileged: true
container_name: bitcoind
volumes:
- /root/project/run_btc_testnet4/data:/root/.bitcoin/
command: ["bitcoind", "-testnet4", "-server", "-rpcuser=demo", "-rpcpassword=demo", "-rpcallowip=127.0.0.1", "-rpcport=5000"]
ports:
- "8333:8333"
- "48332:48332"
you can afterwards log in to the running container like this: docker exec -it bitcoind /bin/bash
and start cpu mining like this (replace my address by yours offcourse) cpuminer -a sha256d -o http://127.0.0.1:5000 -O demo:demo --coinbase-addr=tb1qumlhr8tn9gsdyujy464jkk4c5r488u8kxteyx5
the problem is the only vps i currently have is slooooooooooooooow (it's a small vps from hostnamaste and they seem to have overloaded their hosts. Logging in takes about 2 minutes, let alone running a cpu miner)... I barely get 20 Mhashes per second (really, not kidding......). I have no idear if the mining actually works, since at this hashrate i will not find anything. update it seems like somebody is running an asic on the testnet4... hashrate is 425 Th, so my 22Mh is < 1/19.000.000 of the current network hashrate... On average, i'd hit one block every >300 years. I just hope this asic-miner turns off his asic from time to time to give the cpuminers a chance... Maybe i have to dust off my old geccoscience compaq... If i remember correctly it hashed somewhere at the 50 Gh range??? At least i'd have 1/8500 of the total network hashrate, and i would be able to mine a block every couple of months... ~sigh~ |
|
|
|
In case you want to run your own testnet4 node: i packaged everything in a container: I did think it deserved it's own thread, since i guess other people might find it handy, and it's also still a work in progress https://bitcointalk.org/index.php?topic=5496494 |
|
|
|
Hi guys, tought i would share my work ( in progress)  I was part of this discussion: https://bitcointalk.org/index.php?topic=5496329.0 It was about a potential switch to testnet4... I quickly pointed out how to merge the pull request for testnet4, but last night i started to think: i want to do this in a reproducible way... So i created a docker image you could easily run yourself... FROM ubuntu:22.04 AS builder
#start.sh sets proxy for apt, needed for my env...
#COPY start.sh /usr/local/bin/
#RUN chmod +x /usr/local/bin/start.sh
#RUN /usr/local/bin/start.sh
#install all prereqs
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install -y tzdata && apt-get -y install git autoconf pkg-config libtool build-essential bsdmainutils libevent-dev libdb-dev libdb++-dev clang python3 libssl-dev libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev libminiupnpc-dev libzmq3-dev libqt5gui5 libqt5core5a libqt5dbus5 qttools5-dev qttools5-dev-tools libprotobuf-dev protobuf-compiler libsqlite3-dev ccache
#pull pr
RUN git clone https://github.com/bitcoin/bitcoin.git /bitcoin
WORKDIR /bitcoin
RUN git fetch origin pull/29775/head:pr-29775 && git checkout pr-29775
#compile
RUN ./autogen.sh
RUN ./configure --with-incompatible-bdb CC=clang CXX=clang++
RUN make -j "$(($(nproc) + 1))"
WORKDIR /bitcoin/src
RUN strip bitcoin-util && strip bitcoind && strip bitcoin-cli && strip bitcoin-tx && strip qt/bitcoin-qt
#multistage
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y libdb5.3++-dev libminiupnpc-dev libevent-dev libzmq3-dev libsqlite3-dev
COPY --from=builder /bitcoin/src/bitcoin-util /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoin-cli /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoin-tx /usr/local/bin
COPY --from=builder /bitcoin/src/bitcoind /usr/local/bin
COPY --from=builder /bitcoin/src/qt/bitcoin-qt /usr/local/bin
you can either build the image yourself (should be reproducible), or you can use the image i built: https://hub.docker.com/r/mocacinno/btc_testnet4Afterwards, create a simple docker-compose.yml version: '3'
services:
bitcoind:
image: mocacinno/btc_testnet4
privileged: true
container_name: bitcoind
volumes:
- /root/project/run_btc_testnet4/data:/root/.bitcoin/
command: ["bitcoind", "-testnet4", "-server", "-rpcuser=demo", "-rpcpassword=demo", "-rpcallowip=127.0.0.1"]
ports:
- "8333:8333"
- "48332:48332"
Ofcourse, change the volume path to a path that exists on your host, and change the rpc user and pass Then it's just a matter of "docker-compose up -d" to pull the image and start bitcoind. Connect to the running container and create a wallet: docker exec -it bitcoind /bin/bash
bitcoin-cli -testnet4 -rpcuser=demo -rpcpassword=demo createwallet mywally
a (testnet4) tipping address: tb1qumlhr8tn9gsdyujy464jkk4c5r488u8kxteyx5 (only send testnet4 tBTC!!!)  |
|
|
|
How to do this, on sles 15 sp4 (but should work on any linux distro) Part 1: pull the pull request git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin
git fetch origin pull/29775/head:pr-29775
git checkout pr-29775
git merge origin/master
at this point, you'll see a merge conflict... You'll need to edit src/ini t.cpp manually (open it with an editor and look for <<<<<<<). Some editors (like visual studio code) will make it very easy to solve merge conflicts. then, after resolving the merge conflict git add src/init.cpp
git merge --continue
Now, you can build Tomorrow i *might* add a how-to build doneedit: fixed a typo (thanks LoyceV) |
|
|
|
96 - mocacinno 97 - mocacinno Thanks |
|
|
|
|
Eventough a hardfork is always a strain on the community, i have to say that a hardfork solving this mempool flood would be interesting. I'd defenately think solving the mempool congestion with those inscription thingies would be a better cause than the last "big" hardfork (BCH).
If such a fork would exist, i'd think it would have a reasonable chance of getting adopted by the majority (depending on how many of the core dev's were willing to switch to said fork).
If enough users adopt the fork, miners would eventually switch since big adoption usually means an OK FIAT value, and eventough the block reward is getting lower, money could still be made mining the "new" fork. Personally, i think it would be great being able to make a transaction that doesn't need 200 sats/vbyte to have a decent chance of getting confirmed in the next couple of blocks... I'd also think it would be a good idear if the nodes didn't have to fill their disks with nonsense data when they store the blocks.
And censorship? What censorship? Those inscription thingies could still exist in the "old" chain. If they want to keep filling blocks with their data, they can do so, just not on the "new" chain... If somebody wants a chain to store even more ridiculous stuff, they can make their own fork, and if they gain some adoption, they have a network and they can store whatever they want... I don't see creating a hardfork to see if it gains adoption as censoring.
I'm not saying it's a good idear per sé, i'm not saying i would blindly follow such a fork, i'm just saying that such a fork would probably have more merit than BCH, and eventough BCH did not gain the biggest part of the community, it does still exist.
|
|
|
|
|
You either have to edit your bitcoin.conf file and add the line prune=<Number of Mb> or start bitcoind with the parameter --prune=<Number of Mb>. In windows, you could probably make a shortcut to your bitcoind.exe or your bitcoin-qt.exe, edit said shortcut and add -prune=<Number of Mb> to the command line itself, then use said shortcut to start your daemon or gui... Afterwards, you could look in the directory structure that was generated for the bitcoin.conf file and add the prune=<Number of Mb> to said file, so you cannot start your client without pruning by mistake.
Do realise a pruned node will still download all blocks, but it will prune those blocks after they've been parsed, so they don't occupy all that much space on your disk.
The upside of running your own node is that you've verified every block yourself, all the way to the first (genesis) block. By running a node you're also part of the decentralisation of the network. Oh yeah, one more big upside is that you're able to increase your privacy if you set everything up right.
The biggest downside (in my opinion) of running a pruned node is that you should not import other keys/addresses. If your node is forced to rescan the blockchain, it has to download every block again, since a pruned node removed most blocks after parsing.
Personally, i'd probably advice you to just buy a bigger disk to store everything (if feasible offcourse)... A 1Tb disk is pretty cheap nowadays.
Ps: you don't have to wait to long to check if pruning was enabled correctly, just look at your debug.log file in a file editor, it should mention the fact that Pruning was enabled.
|
|
|
|
|
48 - mocacinno
49 - mocacinno
Thanks!
|
|
|
|
The talk was about avoiding trolls and I don't remember the name of the software. Can someone help?
Trolls on bitcointalk? I just use the ignore button... Anywhere else: probably a tampermonkey script??? If not, maybe you should expand on what you're actually looking for: where do you want to avoid trolls, and how? |
|
|
|
|
Sorry, but this seems like clickbait to me... 72 "sleeping" unspent outputs were spent since the beginning of this month... Personally i'm not alarmed.
The service you created is perfectly fine... Some people will certainly be interested in your site, but there's not need to alarm people in order to get them to visit your site.
|
|
|
|
|
You can always ask your campaign manager to roll over your payments untill a certain value has been reached... I know several members did this in the past, and i would have no problem doing this right now (since i trust the campaign manager i'm currently working with).
An other solution would be to open a lightning channel between the manager and the participant. An opening transaction that *should* have a sufficient value to cover a full year of weekly payments and one closing transaction after said year would replace 50 small transactions. It might not even be required to open a channel between the manager and the participant if both have sufficient open channels with value on both sides to begin with (eventough small fees will arise if there isn't a direct channel between manager and participant).
Or, like said by other members: altcoins
Or, just consolidate the UTXO's when the fees dip.
|
|
|
|
|
i'm just brainstorming here, but i imagine such a proposal would result in everybody spending all their unspent outputs at least once a year to avoid the tax... This would result in more broadcasted transactions, fuller mempools, blocks that are consistently completely filled and a fee war???
In other words, would forcing everybody to spend all their unspent outputs at least once a year result in higher fees for everybody? I'm sure miners would be happy, but the rest of the network not so much.
|
|
|
|
|
Show Posts
