lunar
Well-Known Member
- Aug 28, 2015
- 1,001
- 4,290
you should do a version with the classic can ;-)
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
[doublepost=1455642447][/doublepost]almost closed the gap; already:
bouncing as expected. mind you, i think this is a counter-trend bounce that will fail. just not until everyone is squeezed back out:
bouncing as expected. mind you, i think this is a counter-trend bounce that will fail. just not until everyone is squeezed back out:
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
That's something I've played with...@Mengerian: it is also a deliberate ploy
If anyone is interested my latest project involves playing with QR codes i am making from scratch (surprisingly complicated little things) in python. My idea is to create a digitally created 'mask' composing dots and the components of a QR code randomly arranged over the top of a digital image with actual QR codes within the image (perhaps rotated).
Something like this ^ but on a much larger scale with the aim being to create a wall canvas sized image i can print out onto aluminium and hang on the wall. The idea is to hide one or more QR codes in the image of which one for example could be a BIP38 private key..
Pushed to the edge of readability so YMMV
Next step would have been to find a way to disguise the registration squares.
This is very bad, and pretty much every Linux application that talks to the internet is vulnerable:
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
extremely bad. glibc is a building block for all C based applications running on linux. unfortunately this applies also to any bitcoin core derivatives (core included).
a temporary workaround is to disable any functions that rely on DNS lookup resolution, if possible.
Last edited:
albin
Active Member
- Nov 8, 2015
- 931
- 4,008
Humorous tangent, today I learned that in the normal world out there, RBF is an abbreviation for "resting bitch-face"! Someone completely uninvolved in Bitcoin texted that abbreviation and it took me a moment to get over my confusion over why miner tx selection policy was suddenly in the convo completely out of nowhere.
[doublepost=1455648694,1455647595][/doublepost]time to grab some Bitcoin:
LARRY SUMMERS: It's time to kill the $100 bill
http://www.businessinsider.com/summers-time-to-kill-the-100-bill-2016-2
LARRY SUMMERS: It's time to kill the $100 bill
http://www.businessinsider.com/summers-time-to-kill-the-100-bill-2016-2
No easy fixes.
- Patch the source code to glibc and recompile is the most straightforward (easiest if your Linux distribution is source-based)
- Disable DNS resolution entirely.
- Wait for your Linux distribution to provide an update
a.k.a. steganographyA private key hidden in plane sight, I like it.
protect your nodes running bitcoind with this pars:
-externalip=<your pubblic IP address> -dns=0 -dnsseed=0
add peers to your bitcoin.conf manually using:
connect=known_IP_1
connect=known_IP_2
etc etc
that way if your bitcoind us the only service exposed to the internet you could be safe in relation to this particular vulnerability.
I don't if this is enough I've to look deeper in the docs, though
go, go, go!
[doublepost=1455655600,1455654703][/doublepost]
-connect=<ip> Connect only to the specified node(s)
that's a very specific command and will NOT actually serve to help the network as it means your node won't accept incoming connections and thus not serve up blocks or relay tx's. that's not going to help Classic bootstrap at this point.
https://en.bitcoin.it/wiki/Running_Bitcoin
plus, the bitnodes IP's could be dynamic. also, no one knows who's running them or if any given one is one of those fake nodes.
[doublepost=1455655600,1455654703][/doublepost]
i think we need to research a better soln before making changes.
-connect=<ip> Connect only to the specified node(s)
that's a very specific command and will NOT actually serve to help the network as it means your node won't accept incoming connections and thus not serve up blocks or relay tx's. that's not going to help Classic bootstrap at this point.
https://en.bitcoin.it/wiki/Running_Bitcoin
plus, the bitnodes IP's could be dynamic. also, no one knows who's running them or if any given one is one of those fake nodes.
@cypherdoc
this is a temporary workaround. until your system won't get patched yu are exposed to nasty things every time a running program on your server perform DNS lookup.
As soon as your box is patched you're safe again to operate your node using DNS as a discovering mechanism.
this is a temporary workaround. until your system won't get patched yu are exposed to nasty things every time a running program on your server perform DNS lookup.
As soon as your box is patched you're safe again to operate your node using DNS as a discovering mechanism.
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
I think you want -seednode=
-seednode=<ip> Connect to a node to retrieve peer addresses, and disconnect
You probably only need the one node. You could get it from bitnodes.
I think the attack surface is fairly small in any case though, especially if you are using an external DNS server (such as the one provided by your ISP)
-seednode=<ip> Connect to a node to retrieve peer addresses, and disconnect
You probably only need the one node. You could get it from bitnodes.
I think the attack surface is fairly small in any case though, especially if you are using an external DNS server (such as the one provided by your ISP)