 Show Posts
|
|
Pages: [1] 2 3 4 5 6 »
|
I get mad when people say we take bitcoin, only to find you have to use some preferred service, have a wallet with them, in order to make a payment, I don't know of too many places that will just say send some coins to X btc address. They all want you to sign up with their partner vendor, buy coins from there (most of those vendors won't let you send your coins to them either, you can only populate your wallet with them if you buy coins from their platform), then spend the coins from an account with coins but not a real btc transaction! Yeah, no thanks. I'd use BTC as a means of payment for more expensive items if people would take it by just saying send coins here, like the scam emails saying I've watched some bad porn always say.  |
|
|
|
|
Ahh, ok. Makes sense. I used to only back it up manually after I've made some transaction (I only do a few transaction/year), but recently I put in an offsite backup job and it's backing up stuff that has changed every hour now and I see in the log getting backed up several times/day, was just wondering why.
|
|
|
|
|
Under bitcoin core (currently 0.20.1) full node full chain I'm just curious why wallet.dat file keeps changing a few times day even though I've made no transactions nor generated any new addy's or done anything??? I understand and expect stuff in blocks dir and chainstate dir to change but why is wallet.dat file changing?
|
|
|
|
That sounds like a DOS attack, to be honest. I usually see weeks pass without a single connection from an actual SPV client, though there are bunch of shitty spy things that pretend to be them. It absolutely shouldn't be making remotely that kind of difference.
uh, also, 125 is the maximum connections.
The only issue it exposes you to are DOS attacks and any bugs in that functionality... though bugs seem fairly unlikely at that point. The DOS attack issues have been exploited in the wild, so for a rarely used and not very useful functionality.
I had upped the max with -maxconnections=500 a while back. All I can say is I have the upload bandwidth to deal with it and it was managed via myfirewall as low priority so any other traffic would supersede it and choke it off. So I guess I never noticed how much it was using on a constant basis, only every time I looked it was 120+ connections inbound and serving 10's of gb/day. I cut off mainchain with the bloom, it's now at 61 inbound after 1.5days in that mode and has served 24GB in that time Mabey all those SPV or possible DoS people were blocking out real nodes? DoS attacks suck. But does seem like it's rather pointless in this context. I dunno, I leave it off for now. Sounds like SPV clients are on the way out anyway in favor of other lite methods, might as well show them the door. It's not Gov't, it's just my vote with my node.  Plus if I can use the bandwidth to serve other nodes thats serve the community, that's a better use of the bandwidth IMHO. |
|
|
|
Apparently there are, because if I turn them on my "inbound" connections go from 20-50 to 120-200 . And over a typical days time I would serve out 30-40GB where in the last 24hrs on 0.19.1 with them off i've served 8gb. After reading some of the responses and their material and other info about it, I think I now kinda get it. While the bip allows the client to be lite, it's heavy on the node's it's attaching to because it asks for more than it needs in an attempt to obfuscate which stuff it really wants to know about. So, taking more than it gives...to the community, in a sense. And the whole reason it asks for more is rather moot because if a node wanted to, it can figure out what ithe client is really after anyway. Correct me if I'm wrong, but after reading some material on it, the privacy risk seems to be the clients and not mine, the risk is if I was running a node with intent to do something with that info the SPV clients expose to me. I've just read certain things and opinions, like: - your not a full node unless your offering bloom filters. - CUtting it off is playing government it's an allowed bip and not offering it is attempting to encourage others behavior, aka, trying to tell them what to do - your node will be overrun with DOS attacks stuff like that. Surely, it's up to me. Was just trying to edumacate myself to the best of my ability to decide. I appreciate the education and responses! |
|
|
|
|
I've been running core for years on mainchain and testnet.
I just upgraded from 18 to 0.19.1. I noticed my inbound connections were far lower than normal. Usually was in the hundreds and was just in the 10-20 range after 15 minutes back up, and I noticed an inordinate number of peers connecting and going immediately away.
So I read NODE_BLOOM is off by default now in 0.19+ versions which is why my connection counts are down.
I never really minded it before, I did had to set my firewall's bandwidth manager to make that traffic low priority because it would use alot of my upload bandwidth and cause other things I really need to be slow, which worked just fine for years, that's what the bandwidth manger feature in my firewall is for, let it use it when nothing else wants to, when something important comes along, choke off the bitcoin node traffic. Worked fine for years.
I'm fairly technical generally but not really up on the technical details of bitcoin clients and code. From reading the release notes the developers kinda make out NODE_BLOOM as evil. Apparently this was accounting for a large percentage of my node's traffic, so are these evil? Are these just other peers taking more than their giving? Are clients wanting to use NODE_BLOOM doing things incorrectly and shouldn't be doing it? Should I turn it back on? I turned it back on for testnet.
What's the general consensus on nodes who allow or don't allow NODE_BLOOM?
|
|
|
|
|
I think KuCoin is the newexchange. Since your coin is placed on 5 exchange, trader can easily convert to their desired coin from NWC. Great
|
|
|
|
|
Well..I finally figured it out with the help of <gmaxwell> on irc bitcion chat.
He mentioned it could be some firewall somewhere that is matching something in that block to an antivirus signature
He was right, I turned off my sonicwall gateway antivirus and it started moving and fully sync'd right up.
So...an oddball one, hope it helps someone in the future. I turned back on my gateway antivirus after it sync'd. I'll report to sonicwall a false positive, but they likely won't do much about it
|
|
|
|
I turned on some higher level debugging, this is what I get: 2018-07-24 23:27:47 sending version (102 bytes) peer=13
2018-07-24 23:27:47 send version message: version 70015, blocks=1354779, us=[::]:0, peer=13
2018-07-24 23:27:47 sending verack (0 bytes) peer=13
2018-07-24 23:27:47 receive version message: /bcoin:v1.0.0-pre/: version 70015, blocks=1355070, us=71.13.92.62:18333, peer=13
2018-07-24 23:27:47 received: verack (0 bytes) peer=13
2018-07-24 23:27:47 sending sendheaders (0 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 sending ping (8 bytes) peer=13
2018-07-24 23:27:47 initial getheaders (1355313) to peer=13 (startheight:1355070)
2018-07-24 23:27:47 sending getheaders (1061 bytes) peer=13
2018-07-24 23:27:47 sending feefilter (8 bytes) peer=13
2018-07-24 23:27:47 received: addr (31 bytes) peer=13
2018-07-24 23:27:47 received: sendcmpct (9 bytes) peer=13
2018-07-24 23:27:47 received: getblocks (1061 bytes) peer=13
2018-07-24 23:27:47 getblocks -1 to end limit 500 from peer=13
2018-07-24 23:27:47 received: pong (8 bytes) peer=13
2018-07-24 23:27:47 received: headers (1783 bytes) peer=13
2018-07-24 23:27:47 Requesting block 000000000000000f49b212a0150642ebd2204b8b3d2eaa0dd58f83a0ab4e2ce2 (1354780) peer=13
2018-07-24 23:27:47 sending getdata (37 bytes) peer=13
2018-07-24 23:27:47 connection to 123.115.67.133:18333 timeout
2018-07-24 23:27:47 socket recv error Connection reset by peer (104)
2018-07-24 23:27:47 disconnecting peer=13
2018-07-24 23:27:47 Cleared nodestate for peer=13
Not much there, request the next block, and socket recv error. I can clear the whole testnete data dir and request next block works fine until 1354780...stops cold there. pulling my hair out!!! ANyone...suggestions........  |
|
|
|
|
Alright, what gives. This is driving me nuts.
I tried
reindex-chainstate - again stop at block 1354779
reindex - again stop at block 1354779
removing blocks and chainstate dirs - again stop at block 1354779
removing the entire data dir and starting from scratch - again stop at block 1354779
WTF?!?!?!?!?!?!
|
|
|
|
It did manage to get back to 1354779 but it stops there and eventually all my outbounds disappear/disconnect after a while and nothing ever downloads past this block. The blockhash matches that from blockchain.info for that testnet block, why's it having issues getting the next block from the network to get back in sync? Where should I go with this? |
|
|
|
|
Well, that ran up to block 1354775, 4 blocks before where it was stuck before.
all my outbounds then issued me socket recv error Connection reset by peer and it's stuck sitting there again, makes a new outbound immediately gets a socket recv error Connection reset by peer back.
What's the next move? I'm tempted to remove a few blocks from the blocks dir but that's not as simple as it used to be 5 years ago the last time I had something go wrong with a core instance.
|
|
|
|
|
I restarted with a reindex-chainstate.
It's taking it's time, but at least the outbound connections ran up to 8 and are holding at 8 while it does it's re-index.
We'll see if it holds when it gets to current.....
|
|
|
|
I've got a core full node on mainnet and also on testnet running, both for years. Currently on ubuntu with core 0.16.0 On saturday, my testnet node outbound connections dropped to 0 and it's stuck on block 1354779. I've made no changes to my config, firewalls, network, it happened while it was running as I always leave it up, last reboot was weeks ago. I see in the debug log it makes new outbounds but they quickly get kicked off within a few seconds to a few minutes, like my node is considered misbehaving by others or something. No blocks past the one mentioned ever get synced. The mainnet node is running fine. Any suggestions on what move try to remedy this? Any ideas why it happened? Sample from log: [ 2018-07-21 16:13:30 GUI: Platform customization: "other"
2018-07-21 16:13:30 GUI: PaymentServer::LoadRootCAs: Loaded 146 root certificates
2018-07-21 16:13:31 New outbound peer connected: version: 70015, blocks=1354840, peer=0
2018-07-21 16:13:31 socket recv error Connection reset by peer (104)
2018-07-21 16:13:36 Imported mempool transactions from disk: 18657 succeeded, 0 failed, 0 expired, 0 already there
2018-07-21 16:13:37 connect() to [2001:0:9d38:90d7:433:113d:355b:3ed4]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:38 connect() to [2001:0:9d38:78cf:3045:4a12:ed3a:4b8b]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:39 New outbound peer connected: version: 70015, blocks=1354840, peer=4
2018-07-21 16:13:40 connect() to [2001:0:9d38:78cf:7e:9a64:4e77:6860]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:40 socket recv error Connection reset by peer (104)
2018-07-21 16:13:41 71 addresses found from DNS seeds
2018-07-21 16:13:41 dnsseed thread exit
2018-07-21 16:13:56 New outbound peer connected: version: 70015, blocks=1354840, peer=7
2018-07-21 16:13:56 connect() to [2001:0:9d38:6ab8:1c98:3aee:89e0:f3d8]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:57 New outbound peer connected: version: 70015, blocks=1354840, peer=8
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 socket recv error Connection reset by peer (104)
2018-07-21 16:13:58 connect() to [2001:470:a:c13::2]:18333 failed: Network is unreachable (101)
2018-07-21 16:13:58 connect() to [2600:3c01::f03c:91ff:fe2d:799a]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:02 New outbound peer connected: version: 70015, blocks=1354840, peer=9
2018-07-21 16:14:04 socket recv error Connection reset by peer (104)
2018-07-21 16:14:09 New outbound peer connected: version: 70015, blocks=1354840, peer=10
2018-07-21 16:14:10 connect() to [2001:0:9d38:90d7:8bc:1e0b:b275:ab14]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:10 socket recv error Connection reset by peer (104)
2018-07-21 16:14:16 New outbound peer connected: version: 70014, blocks=1354840, peer=11
2018-07-21 16:14:16 connect() to [2001:41d0:800:664::]:18333 failed: Network is unreachable (101)
2018-07-21 16:14:17 New outbound peer connected: version: 70015, blocks=1354840, peer=12
|
|
|
|
On the website now is no more E10, but now they have E9.3 (16t) and E9.2(12t) both say they are their (sudo)10nm dw1228 (same used in E10.1) chip and gives 110w/th They're all over the board with this stuff. What happened to the E10?? The E9++??? Support shows 9.2 firmware, but no 9.3 firmware. 9.3 is listed at $950 and 9.2 is listed at $1150. WHy would you price the higher th unit less? ?? Does 9.3 even exist? I just don't really trust them. The power has always been more than advertised and the e10 looks like nowhere near the 90w/th they said. the e9+ consumers more than advertised although not terribly out of range. Support is non-existent, just look at their very first product the E9, those people who bought those totally got screwed, they basically never even supported them even when they were only weeks old. Why are they making so many different products??? They could barely support it when they had 1 or 2 and I'm just talking firmware updates, hardware support never really seems to have existed. Now they have what... - e9 -- basically while still less than a year old, they say too old no support not even if you want to buy parts
- e9+ -- seems to have been their most stable product although not without issues... lots of reports of bad boards and near zero support, I've not heard of one story where someone sent their broke machine in under warranty and it was actually fixed
- e9++ -- not sure if these ever existed but they were for sale for a while, I guess
- e10 -- advertised but I think never existed, I think just renamed e10.1
- e10.1 -- power seems to have been way off, based on website news they either didn't deliver alot of them or something went wrong with alot of them, they are offering some rebate to people but it's unclear what it's for
- e10.2 -- never seems to have existed, but was shown in chiense version of website for sale for a while
- e9.3 -- http://miner.ebang.com.cn/goods-9.html
- e9.2 -- http://miner.ebang.com.cn/goods-5.html
What the heck. Are 9.3 and 9.2 just attempts to use their underperforming dw1228 chips they were putting in the e10?? These products once you have them...if you can get them...if you want them... is they are what they are. If they work, great, if not, your SOL. I've got 3 e9+ , 2 I bought from them directly though a very convoluted process mostly based on prayers and hope....but I did get them and those 2 work perfect since last fall since I got them aside from the 130w/th, another I got off ebay and it worked for a few weeks and 2 boards of the 3 went belly up...but I think whoever had this machine beat the crap out of it, it looked like it mined in an actual dirt mining pit it was so dirty and caked up. I had high hopes they would have some integrity behind thier company, especially since they seem to have existed making other electronic communication hardware prior to going into the mining business. But...that hope has all been lost. |
|
|
|
1. I know that transaction can't be canceled or removed
2. When I send transaction of 0,5 btc it was not added to blockchain, so just my core wallet show that it was send. So this trasaction wa not confirmed by any miners.
3. To take this coins back to the balance of bitcoin core I remove wallet.dat and restart my bitcoin core. Bitcoin core reated new wallet.dat and I added private key from previous bitcoin wallet.
4. But when integration was dane, bitcoin core was send this transaction once more but before this transaction core automatically send 0,12 btc to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE, which I do not know (I or somebody else never use this address). Maybe this address is the new addres of my bitcoin core and wallet made this transaction to confirm the low fee transaction.
5. I know that these transactions is already confirmed
6. The question is what is this addres? Why bitcoin core made this transaction AUTOMATICALLY to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE? And how to take my 0,12 btc back, if it possible?
Well, the transaction where you sent 0.5btc to 196y4iA7kZHEHVY9NmZqtTRbD76WWV43Cf was confirmed. In that same transaction 0.124 went to 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE . Internally core has a bunch of addresses it uses to send residual balances to, when you send it's actually picking various transactions that were sent to you and they have to add up to the amount your sending elsewhere, or greater, the "greater" part is what gets sent back to your own internal addresses. .... anything in those will show up in your balance however. (you can see this in core if you choose coin control when sending) . My guess is it's one of those if you didn't explicitly send to that address. When you made a new wallet, you didn't import all the keys, is my guess. Do you have your old wallet.dat? Did you back it up immediately before making a new wallet.dat and importing old keys, ie, did you import ALL the keys from your old wallet, there's many more than just keys for receiving addresses that show up in core. YOu can view all of them in the console or dump them all from the console as well. If your sure it's not showing in your final balance, it's in the old wallet.dat, you need to export ALL the keys from there. A simple test would be to just put your old wallet.dat back in place (moving your current one to a safe name/place) and restart core. you should see your 0.124 then. Then export ALL your keys, switch your wallet.dat's again and import them into your new wallet. |
|
|
|
I have some problem with removing the bitcoin transaction. Maybe somebody can help me. I used bitoin core and some days ago. So I remove my wallet.dat file, restart bitcoin core and insert a private key from the previous. So bitcoin core made this transaction once more but before this transaction bitcoin core made another transaction to the bitcoin address, which I do not have.
eb90ebe8d36c6a2fe2080f3a05662dc9cb8cf50a0fec4e8dc61ee3a76c3ea82a
So the question is what is this address and how to recieve my bitcoins back.
You can't undo a transaction simply by re-initializing your wallet. Once the transaction was confirmed in the blockcahin, that's it, there is no going back, no undo, no option to "remove" a transaction. Any core installed on any computer anywhere in the world with any wallet.dat will see this transaction. The blockchain is unalterable once it has confirmed, by design. So, unless you have the private keys to 196y4iA7kZHEHVY9NmZqtTRbD76WWV43Cf or 1K1xArpDHtkmPpg9bNLgpBxTqw8xw3SDPE , you cannot have these coins. Who made this transaction? What was the intent? Where did either of the addresses come from (who has the private keys for them)? Were they addresses from some other wallet you have you were trying to move coins to? The bottom line remains though, unless you have the private keys to those addresses, you cannot have the coins. |
|
|
|
It's called Bitcoin Credit. It allows you to spend an amount you don't have up to (the number of years that address has been in existence X upper most amount of BTC it once had) up to a maximum of 1 BTC total . Examples: I once had 0.25 BTC in an address that has existed for 1/2 year. I'd be able to spend from that same address on Bitcoin Credit of 0.125 BTC I once had 2.45 BTC in an address tha has existed for 3 days. I'd be able to spend from that same address on Bitcoin Credit 0.02013 BTC I once had 1.24 BTC in an address that has existed for 3.4 years. I'd be able to spend from that same address on Bitcoin Credit 1 BTC You have 1 year to pay it back + a fixed 20%, or the bitcoin Men In Black, or Putin, will come for you. The 20%, goes to the core developers to spend on upcoming features. Or beer. I'm kidding, of course. It's just a double spend or an attempt at a double spend. Most times this is not someone trying to spend coins twice in a malicious way. Most times, but not always there are many reasons it could be..but most times it is someone who submitted a transaction with too low of fee and re-submitted it with a higher fee. Until his 1st low fee trans is dropped, it would show a negative balance. One one would ever confirm. But it takes 3-7 days or more depending on the software that is submitted it, to be dropped. |
|
|
|
The mining software is long gone out of the bitcoin core code (because it was a CPU miner). You will need a stick miner or some piece of mining hardware. A CPU miner won't cut it, even on testnet. A GPU miner may get you lucky on testnet, but I wouldn't count on it. It took my stick miner (25gh/s) about a week on testnet to get a block. No GPu is gonna come close to that. Start bitcoin with -daemon -rpcport=18332 -testnet -rpcuser -rpc password options. rpcallowip is not nessesary but provides extra insurance tha tonly addresses on my local network can use the miner even though my router doesn't route port 18332 from the outside. In my case here is the exact command I use to start bitcoin on testnet with an open port for miners to connect to: bitcoin-qt -datadir=/bitcoin/data -daemon -server -rpcuser=t -rpcpassword=t -rpcallowip=192.168.0.0/255.255.0.0 -rpcport=18332 -testnet Then startup your miner like so cgminer -o http://YourbitcoinServername_OR_IP:18332 -u t -p t --btc-address BTCADDYfromYOURtestnetWALLET --btc-sig ANYBLOCKSIGYOUWANT and any other options specific to your miners hardware In my case this is the exact command I use with a gekko 2pac miner (cranked up a tad) in a specific USB port: cgminer -o http://impalaubu:18332 -u t -p t --btc-address mziZEvRutyzoB3NX1eYv214K67hwYP87bB --btc-sig TheAnoyer --gekko-2pac-freq 225 --usb 2:13 most mining software has the -o address and sig options. user and password doesn't matter, use anything you want just make sure to match them in your bitcoin command and miner command....You'll also want to ensure port 18332 is open on the machine you started bitcion on, most linux have default firewall you'll need to disable or add a rule to allow that port. |
|
|
|
Oh, f-me. I found the issue. MY firewall was dropping it, considering it as an intrusion all of a sudden for some reason. I could see this only after turning on some more detailed loggin on my firewall. Hmmmm... *Packet number: 1841*
Header Values:
Bytes captured: 90, Actual Bytes on the wire: 90
Packet Info(Time:02/04/2018 14:46:45.816):
in:X0*(interface), out:--, DROPPED, Drop Code: 126(IDP detection DROP_IP_IDP_RESET_CONNECTION), Module Id: 25(network), (Ref.Id: _7160_txGsIboemfJqQlu), 1:3)
Ethernet Header
Ether Type: IP(0x800), Src=[00:0c:29:77:dc:aa], Dst=[18:b1:69:16:06:d4]
IP Packet Header
IP Type: TCP(0x6), Src=[192.168.168.81], Dst=[73.191.37.221]
TCP Packet Header
TCP Flags = [ACK,PSH,], Src=[39796], Dst=[8333], Checksum=0x3442
Application Header
Not Known
Value:[0]
Hex and ASCII dump of the packet:
18b16916 06d4000c 2977dcaa 08004500 004cdeea 40004006 *..i.....)w....E..L..@.@.*
832bc0a8 a85149bf 25dd9b74 208dfa48 168ab683 1a108018 *.+...QI.%..t ..H........*
00e53442 00000101 080a07f0 c86e7797 9e44f9be b4d97665 *..4B.........nw..D....ve*
7273696f 6e000000 00006600 0000dc9b 33bf *rsion.....f.....3. *
I made an exception for any src port where destination port=8333 and it instantly started making outbounds again. Holy cow. Now I just need to dig a bit further and find which signature in the intrusion detection signatures to disable as I think that will be better than an exclusion rule. Those signatures update automatically (like virus definitions) from the firewall manufacture (sonicwall in this case). |
|
|
|
|
