Bitcoin Forum
December 05, 2020, 11:05:00 PM *
News: Latest Bitcoin Core release: 0.20.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 »
1  Other / Meta / Re: Stake your Bitcoin address here on: June 20, 2017, 07:00:12 AM
Message with previous quoted address: NOT verified (using my own tool + https://tools.bitcoin.com/verify-message/)
Whoops. This should be signed correctly:
Code:
-----BEGIN BITCOIN SIGNED MESSAGE-----
Achow101_alt staking a new address 1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM on June 20th 2017. Current best block hash is 0000000000000000015e22405e714d4475cc70ef604641713e54478996f51fbb
-----BEGIN BITCOIN SIGNATURE-----
1At6EhbjN8BLCJz4pVAjsFcNzhzxQmXrwZ
HJJGQP+dF3O/81fMFPTcYCG2NnNRhJ1fzRth49Z8+PcrSL1LWcZ3jetQmikrYFwlk12cfB2hoL4tFJZjrfyr8CY=
-----END BITCOIN SIGNATURE-----
2  Other / Meta / Re: Stake your Bitcoin address here on: June 20, 2017, 06:41:57 AM
Staking a new address: 1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM

Signed message with previous staked address
Code:
-----BEGIN BITCOIN SIGNED MESSAGE-----
Achow101_alt staking a new address 1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM on June 20th 2017. Current best block hash is 0000000000000000015e22405e714d4475cc70ef604641713e54478996f51fbb
-----BEGIN BITCOIN SIGNATURE-----
1At6EhbjN8BLCJz4pVAjsFcNzhzxQmXrwZ
G2YuaQ+kYe/XMSXktKs2sjAI8YZcDMO+XQpJEkTlKjVtlONDPgbeCSYtfJH1Yu6C9mtBpFnNvUTC6PIEC28lYnA=
-----END BITCOIN SIGNATURE-----

Signed message with PGP key:
Code:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Achow101_alt staking a new address 1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM on June 20th 2017. Current best block hash is 0000000000000000015e22405e714d4475cc70ef604641713e54478996f51fbb
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZSMNbAAoJEBdWVzLgjl5BAngP/i+OS6a7eq+37MeDNz048Yhw
BIe+ur9qcMCeaEoEbMwcXrEhu1sPcUKLTAop+8k9pvpn9vCdawEu53ftAiB5uDBD
pVRKsgLFhwkyl1y+ay9QYdaNTECOTlrUxT6GqZuWTd3HdGioadD0cSnKBudA3A8d
+GnS7jfkP0NpzexkXEmELSVMh7Ej/145aS6tkXnQGNKffTu3IY3ZRCsgKoULzPwi
7V4dnb9ObprqB/Aacc+viOzCG5eQF8WNjqwGYR+HjvpsXV5JadVdi8dBREPsfMIM
iwtLv+MSsRZLp//Bkq2JOgxLQ+onY+B0Kou+lWAJQ1L9p7sML2liMmBHQsSTdHCX
Ge0OilKjr4X8+LlqzhoOuimykG6bpYlzgt6h0/sJuPDOTVn/qOnKYqRc1bosRheD
XOmx0Y7ycpumc9c1FUcVAIQ9BVkMebf5xsecO+TY+71PcWEVGV4T5wNp0OhlSc/S
2uhh+zbluh8ADxGD8qR0qxzZzfAjt+r9K83Zx7HSb81HsI65SpS341KgRRfOGhi0
xAgWbl/TSXOJAjpQ0P9KLaQnFg0hoQQ0MM/eieb3FIjzaCzDO+wGpzFez7jaRJqR
XQYqR3BxkPp8MgEN+GuSSchnxvyvI3NtPv1RpUXpw7Rm1k7vOKxhIIn++U7PRw0/
bEbGjh7XVwL/QxPYSrV6
=9TeR
-----END PGP SIGNATURE-----
andy@andy-ThinkPad-P50:~/electr

Signed message with new address
Code:
-----BEGIN BITCOIN SIGNED MESSAGE-----
This is a message verifying that I, achow101_alt, own the private key to 1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM on June 20th 2017. Current best block hash is 0000000000000000015e22405e714d4475cc70ef604641713e54478996f51fbb
-----BEGIN BITCOIN SIGNATURE-----
1AQx99s7q1wVinbgXbA48BaZQVWpHe5gYM
IGCu1TMh1VgCzIttEdpjvPeV2lXK/SmbPor8NR4wf4s1Y2HLwUTzQaTLIJJrGjN3+XX5VsJY2ksUuBkCgDugSvg=
-----END BITCOIN SIGNATURE-----
3  Bitcoin / Bitcoin Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: February 01, 2016, 01:09:39 PM
I think it will be more complex to implement that kind of network type prioritisation. Suppose that you want to prioritise IPv6 over IPv4. How do you manage the threshold of the number of IPv6 peers before you allow IPv4 peers to be connected to the node and being connected from the node? How about if the nodes would never reach that threshold, resulting you have less IPv6 peers and no IPv4 peer for a long time? Would you use a dynamic timer to avoid that issue? As the network is dynamic, would you keep maintaining the number of IPv6 peers to always above the threshold regularly? Or would you manage that base on the timer? And so on Smiley

And if you manage to find the solution for that without increasing MAX_OUTBOUND_CONNECTIONS or the maximum outbound connection slots remain 8, the chances that the node will have less IPv4 peers for longer time than before the implementation of your solution is quite high.
My implementation would be to connect to as many nodes as possible until there are none able to connect to or the outbound connections are full.

For example, with IPv6, it would search the local database for all IPv6 nodes and attempt to connect to all of them. Then it would ask for peers and connect to any IPv6 that it's peers gives to it. After either all 8 outbound connections are taken or there are no remaining IPv6 nodes that can be connected to after searching through the databases described above, it will make outbound connections to IPv4 nodes if any outbound slots are available. It would accept any incoming connections from both IPv4 and IPv6.
4  Bitcoin / Bitcoin Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: February 01, 2016, 03:59:17 AM
Thanks for your comment. That makes sense to me.

I think the fundamental problem is that, Bitcoin software only allows maximum 8 outbound connections regardless how many available IP addresses on the node. A part from obsolete implementation, i.e. based on only IPv4 network, I think the intention is possibly also to avoid bad nodes with multiple IP addresses flooding the network.

Due to that 8 outbound connections limitation, it is quite likely that my nodes always connect to IPv4 peers first and they will be quite fast occupying the whole 8 outbound connection slots. For the same reason, the likelihood for my nodes to get IPv6 peers to connect to them is also quite low as all of those IPv6 peers experience the same issue, i.e. 8 outbound connections limitation, unless they are solely running on IPv6. I think this is what causing the propagation of IPv6 nodes into the whole network very slow.

I can easily change the MAX_OUTBOUND_CONNECTIONS on net.cpp and re-compile my bitcoind. But I am quite sure that will not solve the problem, because my nodes will first connect to the available IPv4 peers and occupy the whole outbound connection slots again.
I think that is actually a bad idea. You run into memory issues at some point and having more connections takes up more bandwidth. I tried setting MAX_OUTBOUND_CONNECTIONS to something really high before and it crashed the program. It just took up way to much memory.

I think the solution is to separate the maximum outbound connections per IP address types. So that each IPv4 and IPv6 addresses individually get maximum 8 outbound connections as they are clearly on separate networks. For this reason I raised this feature request. Unfortunately, I am not a hard core programmer otherwise I would fork Bitcoin, create a patch and pull request it.
I think it might be better to have an option to prioritize one network over another e.g. get as many IPv6 connections as possible before getting IPv4 connections.

I think I will try writing some code up and submitting a PR for that.
5  Bitcoin / Bitcoin Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: February 01, 2016, 12:48:32 AM
You clearly already know everything and don't need any help. Sorry to disturb you. Have a nice day!

Please don't get me wrong. If I knew the reasons of the problem, I would not ask the question in the first place.

However, you didn't actually answer my main question, especially on why Bitcoin node does not automatically connect to the available IPv6 peers while I can manually force it to connect to the IPv6 peers.
It has to do with how node discovery works. Your node has an internal database of nodes that it will try to connect to. That database is built by nodes that you have previously connected to (so it will include your IPv6 peers from the past) and nodes that your peers have announced to you. Given that you have only connected to a few IPv6 nodes, then your database of available IPv6 nodes is probably very small. Since you can only have 8 total outgoing connections, your node is unable to connect to other IPv6 nodes that it knows about once all 8 connections are taken. After that, you just have to wait for other IPv6 nodes to connect to you, and you have no control over that whatsoever. All you can do is hope that your peers announce you to its peers and that your IP address makes it onto a DNS seed so that new nodes may be able to see your IPv6 Address and connect to you.

Basically it all really has to do with how there are significantly less IPv6 nodes than there are IPv4 nodes and that the addresses of those IPv6 nodes is not propagated through the network.

To get more IPv6 nodes, you could force your node to only accept IPv6 connections or force it to get peers from the DNS seed which will probably return more IPv6 nodes for you to connect to.
6  Bitcoin / Project Development / Re: Let's create a Bitcoin Node Radio Network on: January 20, 2016, 08:51:10 PM
Anyone know anything about radio and can help me here?
7  Bitcoin / Project Development / Re: Let's create a Bitcoin Node Radio Network on: January 14, 2016, 09:28:06 PM
I think that already exists... There is even a technology that allows people to send BTC via RADIO signals.

http://tunein.com/radio/Bitcoin-Talk-Radio-s250329/
That is a radio station, not what I am talking about

This one doesn't allow full nodes and it isn't what I want to build. The idea behind mine is that it can fully sync a new full node and uses a p2p radio network. That article sounds like the project relies on a centralized radio broadcast and does not allow full nodes.
8  Bitcoin / Project Development / Let's create a Bitcoin Node Radio Network on: January 13, 2016, 09:25:46 PM
I have been thinking about this for a little while, but I am not an expert in radio and am relatively new to the field so I could use some help from people who know what they are doing.

As we know, not everyone in the world has access to the internet, has a decently fast connection, or has a connection that isn't blocked. To get around these problems, I propose that we should, as a community, create a radio network that allows the relaying of blocks and transactions without relying on internet connections which we have no control over. It would facilitate the use of full nodes and the accessibility to the Bitcoin network especially to third world countries where the internet is not available. Such a network would also help in places where there is a lot of internet censorship like in China. It would be able to bypass internet filters since those inside the country would still be able to pick up signals originating in neighboring countries.

Ideally this radio network would be on a frequency that can carry a lot of data, has a wide range, has little interference, and is legal to use worldwide. It should also be able to be broadcast to and from space so that we can have satellites that operate as full nodes and can further connect nodes to each other.

Part of the problem is finding a frequency that can be used for this. We could use CB frequencies but those are not able to carry a lot of data. Higher frequencies would require having an amateur radio license and may also be crowded and thus we would have interference. The best case would be to buy spectrum specifically for Bitcoin radio use only.

To transfer data, we could use already existing technologies. We could use the existing Packet Radio stuff and use the de-facto packet radio standard, AX.25. With this we could wrap blocks and transactions in a special message and send the packets with packet radio in order to propagate those blocks and transactions.

I will be working on this project to develop a Bitcoin radio network on and off. Currently I do not have the equipment for implementing or testing any of this, the proper licences, or the experience and knowledge. If anyone is more knowledgeable in radio, specifically packet radio, then the help would be appreciated.

Let me know what you guys think of this idea.
9  Bitcoin / Bitcoin Discussion / Re: Need help releaseing funds from time locked address on: December 30, 2015, 03:36:37 AM
Have you tried submitting the transaction elsewhere? IIRC nonfinal transactions (which include OP_CLTV transactions) are considered nonstandard so they are not relayed by many nodes. However there may be an exception to that with OP_CLTV.

Edit: I think I found your problem. It isn't the time specified in your transaction yet so you will need to wait until then to spend the funds. It is currently 12/30/2015 @ 3:56am (UTC) but it is locked until 12/30/2015 @ 5:00am (UTC)
10  Economy / Web Wallets / Re: Blockchain.info Receive Payment callback problem on: December 30, 2015, 03:35:04 AM
Do you have the correct ports open on your server to accept the callback connection?

Also this could be a service problem since blockchain.info has had some service problems in the past. If you can ping your callback URL from another computer, then it is probably open and working as it should. In that case then contact blcokchain.info's support since that would be their service not sending the callbacks.
11  Bitcoin / Bitcoin Technical Support / Re: 0 confirmations after 10 hours, 0.0001 tx fee, what's wrong? on: December 22, 2015, 10:38:46 PM
A service in a pool (where for sure some blocks will be mined) were you can pay a fee and tell them your txId and make them include automatically in next block. If they implement it would be an extra BTC earnings for the pool operators.

There are talks about changing the bitcoin protocol to allow adding fees to sent txs, or child-pay-for-parent type systems. We are not there yet, so for now, we need to place enough fees into txs before we send them. It's not difficult to get used to Smiley

Bitcoin Core 0.12 will support Opt-in RBF so that if you opted in then you can increase the fee by resending the transaction. Opting in involves having a different sequence number in the output.
12  Alternate cryptocurrencies / Service Discussion (Altcoins) / Re: Withdraw from cryptsy to drachmae on: December 22, 2015, 10:35:57 PM
Anyone who can confirm this for me where the coins really are? Both exchange have still the same balance. It confusing me and don't wanna lose mine coins.
As you can see in the confirmed transaction, the coins are really in drachmae. This is a problem with Cryptsy, probably a bug. If you can withdraw the same amount again, then you should let them know that you found a bug in their exchange.
13  Alternate cryptocurrencies / Mining (Altcoins) / Re: GPU only works on CUDAminer, can't play games on it anymore on: December 22, 2015, 10:34:28 PM
Have you checked that the driver it uses is the one you installed? Check in the device manager.
14  Alternate cryptocurrencies / Service Discussion (Altcoins) / Re: Withdraw from cryptsy to drachmae on: December 21, 2015, 01:28:52 AM
Since that transaction is confirmed, those coins should now be in the drachmae exchange. This might just be a service problem.
15  Bitcoin / Bitcoin Technical Support / Re: Upgraded to 0.12 now RPC calls giving 401 Unauthorized on: December 21, 2015, 01:27:39 AM
There shouldn't be anything that is causing this. I don't think there were any changes to the RPC server for 0.12.
16  Bitcoin / Bitcoin Discussion / Re: Why is there such a big problem with Satoshi? on: December 10, 2015, 10:10:02 PM
Because people want to know who Satoshi is, and the fact that his identity is unknown increases the mystery and the curiosity that people have.
17  Bitcoin / Bitcoin Discussion / Re: Satoshi returns, says he's not Craig wright on: December 10, 2015, 10:06:54 PM
I didn't check the headers, so I didn't notice this. That is very convincing that it is not Satoshi. But how can that domain name be spoofed? Does the sender set that name or is it done by the receiving server?

Here's apparently the person who sent it, explaining how he did it.

In SMTP (the email protocol), you start your connection by saying who you are via a command like HELO bitcointalk.org ("hello, I'm bitcointalk.org"). Most servers will then check that the IP address you're connecting from actually matches the hostname you give, and if not will immediately drop the connection. But the mailing list's server is apparently really stupid, and just blindly believes that any given hostname is actually accurate. So you could tell it HELO whitehouse.gov and the server will believe that you're whitehouse.gov. Or whatever.
Well that explains a lot.
18  Bitcoin / Bitcoin Discussion / Re: Satoshi returns, says he's not Craig wright on: December 10, 2015, 09:28:37 PM
This is spoofed.

Code:
   Received: from mail.vistomail.com (cpe-104-231-205-87.wi.res.rr.com
     [104.231.205.87])        
     by smtp1.linuxfoundation.org (Postfix) with SMTP id 01BCADF
     for <bitcoin-dev@lists.linuxfoundation.org>;
     Thu, 10 Dec 2015 06:53:42 +0000 (UTC)

104.231.205.87 is not mail.vistomail.com. It's some residential IP, cpe-104-231-205-87.wi.res.rr.com.

I feel like the mailing list must be seriously misconfigured to allow this sort of spoofing... You could exploit this to send mail "from" any of the devs, for example.
I didn't check the headers, so I didn't notice this. That is very convincing that it is not Satoshi. But how can that domain name be spoofed? Does the sender set that name or is it done by the receiving server?
19  Bitcoin / Bitcoin Discussion / Re: Satoshi returns, says he's not Craig wright on: December 10, 2015, 12:52:41 PM
I find it strange that he would do this... Wouldn't he add a signature?
I don't think it is that strange. He has done it in the past when people thought he was Dorian Nakamoto. There is no need for him to prove his identity, people already know that Craig isn't satoshi.
20  Bitcoin / Bitcoin Discussion / Satoshi returns, says he's not Craig wright on: December 10, 2015, 12:43:22 PM
Update: It was not Satoshi.
This is spoofed.

Code:
   Received: from mail.vistomail.com (cpe-104-231-205-87.wi.res.rr.com
     [104.231.205.87])        
     by smtp1.linuxfoundation.org (Postfix) with SMTP id 01BCADF
     for <bitcoin-dev@lists.linuxfoundation.org>;
     Thu, 10 Dec 2015 06:53:42 +0000 (UTC)

104.231.205.87 is not mail.vistomail.com. It's some residential IP, cpe-104-231-205-87.wi.res.rr.com.

I feel like the mailing list must be seriously misconfigured to allow this sort of spoofing... You could exploit this to send mail "from" any of the devs, for example.
See for more details: https://www.reddit.com/r/Bitcoin/comments/3w6vy4/i_am_not_craig_wright_we_are_all_satoshi_satoshi/cxu7blm


I just saw this in the bitcoin Dev mailing list
Quote
I am not Craig Wright. We are all Satoshi.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011936.html

I have no idea if this is legitimate, but it was sent (supposedly) by satoshi@vistomail.com, which is the first email address that he used to post about bitcoin.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!