Currently my biggest confusion is why Gmaxwell quit as main committer, and who will be the next?  He did? Since when? |
|
|
|
Wow, I had no idea I was running a full node!
I thought I had to do some extra steps like unblock port 8333.
It's kinda cool to know I've been running a full node this whole time, without actually realizing it.
If you want to accept incoming connections, you need to open port 8333. That helps the network more but simply running bitcoin core and having connections to the network also helps. |
|
|
|
Bitcoin core supports pruning. You can set it using the -prune=<size> where <size> is the size of the blockchain you want to store. The minimum you can do is 550 Mb. Unfortunately you can't use the wallet yet but that will be fixed in 0.12
Ok that's good news. What do you mean by not being able to use the wallet? I would need to sign transactions and listen for new incoming transactions, that's all what I need. The latter requires a wallet where to keep the private keys for signing. edit: But I could do my thing without wallet functions, all I need is my own (possibly C++) function for signing a raw transaction with the private key I'd provide. I need the pruned mode to allow me to construct raw transactions based on specific outputs, sign them and broadcast them. Is it possible? Wallet functionality in a pruned node was disabled because it was still untested when 0.11.0 was released. It will be enabled in 0.12. You should still be able to broadcast transactions using a pruned node, but I don't know about getting outputs since there is no wallet and txindex is disabled with pruning. However you can just build the master branch from github for now and get the wallet functionality and then upgrade to 0.12 whenever they release it. It should be coming out in a few weeks. |
|
|
|
|
Bitcoin core supports pruning. You can set it using the -prune=<size> where <size> is the size of the blockchain you want to store. The minimum you can do is 550 Mb. Unfortunately you can't use the wallet yet but that will be fixed in 0.12
|
|
|
|
|
Your fees might be a little low, but the problem in those transactions are that one of the outputs in each transaction is a dust output. Dust outputs are outputs that have amounts less than or equal to 0.00002730BTC. Transactions that have dust output are considered nonstandard so they are less likely to be relayed and less likely to be mined as most nodes will reject such transactions. That is the problem with your transactions. All you can do is wait and hope they either get confirmed or are dropped by the network. If they are dropped, then you can resend them but without the dust outputs by either lumping the dust into the other output or into the fee.
|
|
|
|
Of course you can use nonstandard transactions. But they are nonstandard, which means that they do not adhere to the standard rules. The vast majority of nodes will reject nonstandard transactions, which is why nonstandard transactions typically do not propagate very well. If you want to push it to the network and get the transaction confirmed, you will need to find a miner that will include nonstandard transactions into their blocks and you push it directly to them or their node.
Do you have any suggestion where to push the nonstandard transactions? I already tried eligius ( http://eligius.st/~wizkid057/newstats/pushtxn.php) many times but no result. No. Just look around at mining pool threads and see if they say anything about supporting nonstandard transactions. You can also PM the pool operators about it. |
|
|
|
|
Of course you can use nonstandard transactions. But they are nonstandard, which means that they do not adhere to the standard rules. The vast majority of nodes will reject nonstandard transactions, which is why nonstandard transactions typically do not propagate very well. If you want to push it to the network and get the transaction confirmed, you will need to find a miner that will include nonstandard transactions into their blocks and you push it directly to them or their node.
|
|
|
|
Founding Members: one of the original members of an organization, group, or company.
Founder/Co-Founder: The creator of a company/concept.
So by those definitions Satoshi is the sole founder since he is the only creator creator of the thing we call Bitcoin. The other guys, sirius, hal, etc. are founding members since they are of the original cypherpunks group who were interested in Bitcoin and joined the project after its announcement. They are not the founders. |
|
|
|
I don't understand why people think there is only one founder.... When there was a few people part of the initial development. People need to leave them alone, they did good to this world.
No there was not. There was only one entity called Satoshi Nakamoto which penned the original Bitcoin Whitepaper and wrote the code for the original v0.1 Bitcoin client. He was also the guy that mined the genesis block and did a lot of the early mining. Other people jumped on board to help in the early stages but they only joined after Satoshi wrote the whitepaper and they only contributed to code and hash power after Satoshi released the original client. Therefore they are not founders since they did not create Bitcoin themselves, they are only super early adopters. |
|
|
|
I don't think that is possible. It may be possible to do if address B was a p2sh address that used a custom script, but I don't think it will be possible.
I am confused, with a custom script it is possible? Possibly. I don't know as I haven't checked or tried, but it may be possible to create a custom script which requires different private keys. I think the OP codes have enough options for that logic, but as I said earlier, I do not know. You will need to try this yourself. |
|
|
|
|
The best way is to spend it like normal money. There aren't many places that accept Bitcoin, but some online stores take Bitcoin, and you can buy things from amazon using purse.io. AFAIK Newegg, Tigerdirect, and dell accept Bitcoin. There might be some stores in your local area that also take Bitcoin, so you should check some maps and merchant directories like coinmap.org
|
|
|
|
|
I don't think that is possible. It may be possible to do if address B was a p2sh address that used a custom script, but I don't think it will be possible.
|
|
|
|
Dude, the 8 MB limit is not each and ever block. If the cap is 8mb, and the current block size is 0.5 mb , then 0.5 mb blocks will circulate. The 8mb block is only the cap limit, not the default size.
There's no problem with 8MB blocks but do you have a way to deal with stress testers? Do you know how make their tests more expensive? Higher dust limit and Higher fees? Maybe we should go to 2MB first which is a 100% increase. Stress testers? Disable 0 bitcoin fees. If they want to test, pay for it. A stress test is the same as regular transaction. Pay and then they can send as many TX they want. 0 bitcoin fee should be disabled at protocol level. Minimum should be at least 1000 satoshi. There is a minimum, not at protocol level but at the node level which is set by default to 0.00005. Any fee under that is not relayed by the node. Also, the stress tests do not send transactions with 0 fees. They always send with enough fees. |
|
|
|
|
There is nothing you can do to speed up the sync, and if you think you have corrupted blocks then it would be best that you do a full resync. Also make sure that all of your software is fully up to date.
|
|
|
|
It's a standard zip compressed bootstrap.dat file, combining all blk*.dat files out of the blocks directory. The actual bootstrap.dat is not compressed. The one you are downloading is, but it isn't the official one that was maintained by jgarzik. Maybe we should discuss adding a zip level compression (or better suitable) algorithm to the Bitcoin-Qt client to reduce the amout of data needed to be transferred to update the block chain.
There is talk on the mailing list about block compression and ways to speed up syncing, but I don't think that any of it will be coming in the next release. It either isn't ready or there isn't any particular need for it. Using the actual bootstrap.dat (not the one that you used) is not actually faster than simply letting it sync. |
|
|
|
Sorry, but I can not confirm this; at least not if you have access to a very fast internet connection.
The difference is probably negligible if you have a fast connection.  I've just downloaded the latest block chain (bootstrap.dat: 2015-12-10) from Flo's Press 4u: https://flo.sh/bitcoin-qt-bootstrap-dat/uncompressed the zipfile to my ~/.bitcoin application directory and restartet a brand new Bitcoin-Qt v0.11.2. Bitcoin-Qt imported the bootstrap file within minutes. So I'm ready to go (download and unpacking of the bootstrap zip file included) within less than two hours using recent equipment!  Just starting the plain Bitcoin-Qt client would have taken many hours if not days to complete the same task  Nevertheless downloading a bootstrap file may be counterproductive using a slow internet access technology. That is not the actual official bootstrap.dat. That is the file produced by a third party and has also been compressed from 50+ Gb to around 35+. The smaller size makes it faster to download (duh). I was referring to the official bootstrap.dat which is now obsolete and is still the full size of the blockchain, not compressed. |
|
|
|
Does anyone else disagree with the community's view on 'post length'? Sometimes a simple sentence or two is all that's needed - why do most services count the length of posts when a lot of times, 90% is useless filler or repetition? Sometimes, less is more...  Because it is incredibly difficult to define when post quality is when writing a computer algorithm without getting into AI and all that sort of stuff. Post quality is subjective, and really the only way to determine post quality is through reading posts and determining that in you head. There is currently no simple way to put that into a computer program, it isn't objective, which makes it very very difficult. The best way to do that is objectively through the length of the post. In the vast majority of cases, long posts are usually of a higher quality than short posts. It takes more time and effort to formulate a long response, which many spammers do not do. Yes I agree that some short posts are good quality and that some long posts are not, but that is a difficult metric to put into code. |
|
|
|
Also, compressed public keys will begin with a 02 or 03 byte while uncompressed public keys begin with a 04 byte.
True, but if you've gotten that far, then you must already have gotten past the key size. It is a lot easier to just look for that. In most block explorers, the scriptsig is already broken into the sig and the pubkey. They are usually separated by a space, and the pubkey is the second one. Just quickly looking at the first byte can tell you whether it is compressed or not. Even where the scriptsig is not broken apart, most transactions use sighash all, which is a 01 byte at the end of the sig. I usually look for a that 01 in the middle and if it is followed by any of the leading bytes for a pubkey, then in most cases you will have found the pubkey and then you can know which type it is. |
|
|
|
thank you knightdk for your answer but how do you know if the key is compressed or not ?
If the wallet created the address, then it will know what type of address it created. If you wrote your own software for generating addresses, then you should know what type of address you generated. If you can access the private key for an address, then you can tell if it is a compressed key address by the first byte in the private key. A private key in WIF for an uncompressed key address on testnet will start with a 9. A private key in WIF for a compressed key address on testnet will start with a c. If you don't have access to the private key, but you have access to a transaction where the the output has been spent (and if it was a pay-to-pubkey-hash output) , then you can tell by looking at the scriptSig (also known as Txin-script). The first byte of the scriptSig indicates the length (in bytes) of the signature, next is the signature, then the next byte after the signature is a byte that indicates the length of the public key. If the length of the public key is 65 bytes (41 in hex), then the input was previously received at an uncompressed key address. If the length of the public key is 33 bytes (21 in hex), then the input was previously received at a compressed key address. Also, compressed public keys will begin with a 02 or 03 byte while uncompressed public keys begin with a 04 byte. |
|
|
|
(1) Does this whole approach even make sense from the perspectives of security, practicality?
kinda (2) If this is do-able, would I need some kind of encryption to use when sending a signed transaction from some internet cafe to the remote online machine via ssh?
You do not need any extra encryption. SSH is already encrypted. And the transaction will still be sent unencrypted when it goes to the network. The signature on the transaction prevents people from modifying the data (as it is supposed to) and people will still see the details of transaction when it hits the network. (3) Does Armory have the kind of command-line interface which would allow doing all this with no GUI the remote online machine running on Amazon AWS?
Yes. There is a daemon option. I think you should be able to run a watch-only wallet from that interface. (4) This could be the clincher question: What kind of software would I need to be running from this internet cafe? I was hoping I could just quickly install Putty on some Windows machine in an internet cafe and do everything via ssh - but maybe I would need a local machine running a full copy of Armory? In that case, I could probably use yet another machine: it could be my existing online Armory machine, but because I'm travelling and it's been offline for weeks it would not have an up-to-date copy of the blockchain - but it would still have all the functionality of Armory, the python-qt GUI, etc. Then it seems like I'd be trying to create some sort of hookup between:
- the formerly online Armory local laptop with the outdated copy of the blochain plugged in or wifi-ing in at an internet cafe, and
- the up-to-date currently online remote server on Amazon AWS.
... also using a signed transction from the offline machine.
You will need armory on the local laptop. It doesn't need the blockchain to work. All you just do is use a watch only wallet on the server and use that to create the transaction. Then you sign the transaction on your offline laptop using armory. The transaction can be broadcast through the server or through any web transaction broadcast. (5) I think I saw a website once, I think it was a page at blockchain.info, where you could also do something like "upload a signed bitcoin transaction". Is this browser-based method of signing a transaction on a site like blockchain.info compatible with the kind of signed transaction produced by Armory? If so then maybe I could skip all of the above - no VPS on Amazon needed, just keep my Armory offline machine with me and sign transactions from it and submit via any web browser?
First of all, you are not signing the transaction in the browser. You could create and import a watch only wallet into blockchain to create the transaction that you sign. Then take that transaction offline to your armory and sign the transaction and then broadcast it back through blockchain. |
|
|
|
|
Show Posts
