How easy is, for a miner, to find the place in the source code where it says "1 Mb" and remove the line? Very easy. I mean, if most miners, like 80% hashpower, decide to raise the limit of the block size, they can, right? Core developers are neither necessary for this nor can't do anything. Yes - a majority of the miners can do whatever it wants with the protocol. Or saying otherwise, which is much more important from the economical point of view: "Core developers" (whoever that creatures are) cannot do anything with the protocol without a majority of the miners supporting it. |
|
|
|
Hi, I am in the process of creating an offline secure wallet to store my BTC. I am wondering the best way to do this? I am quite paranoid about security so would prefer the approach "the more secure the better", even if it is a pain in the backside to do. So far I have an offline PC (Ubuntu Server, AMD R9 290) I have the following questions. 1) What is the best software to use to create the wallet? I dont know if I trust bitcoind or bitcoincore, I am even happy to write my own software if it is more secure (what would I need to look into to do this) 2) Is there any software out there apart from what I have mentioned that can do this? 3) I understand on Linux that it will be using /dev/random and /dev/urandom, are these truly random enough or is it worth investing in a hardware RNG? ( http://www.entropykey.co.uk/) 4) is there anything else I should take into account, I am going to print it and have a copy of the private key in my safe and in my parents safe, No-one has access to this apart from them. You may also want to check out my software - I created exactly for the reasons you've mentioned; being paranoid about the security. It's open source and you can easily modify it for your own needs, if you are missing any functionality. http://www.assets-otc.com/gocoin |
|
|
|
IMHO, each specific functionality of a node (maybe even each message type), should have its own bit in the services field. I'm talking about the 64-bit field that currently is always set to 1. Using the "version" filed to indicate whether a node supports things like "getheaders", "ping", "mempool", "reject" or bloom filters - this is a mistake. Currently you basically get to choose between version 6000x and 7000x, but the reality is never that simple. For instance: the node I use does not support bloom filters (probably never will), but it does support things like "getheaders" or "ping". And I wish my node could be honest about which commands it will reply or act upon, and which it won't, but with the current protocol this is just impossible to be honest about it. All I can tell you is version 60002, 70001 or 70002 - and none of them will actually be correct. My point is: if the folks developing the core could get advantage of the services field (which shall not be a hassle), I believe the protocol itself (and thus the network as a whole) would have benefited from it. EDIT: Also I'd like to point out that the service field (unlike the version filed) is sent along with IP inside the addr message. So for instance if you have an SVP client, then you could just ignore all the nodes that are not going to serve the bloom filtering for you and never connect to them. |
|
|
|
The cruel thing about blockchain economics is that it's not for Gain, nor for any of his friends to decide about sizes of the blocks.
It's the mining, that he doesn't care of.
So I just wonder what is in this guy's head when he assumes that miners actually care about him and his opinion on a size of their blocks? Who is he actually speaking to with poems like this and what is a point of this?
People who understand the problem know that the key to make bitcoin really scalable and keeping transactions cheap is adding a layer of off-chain transactions on top of the existing protocol.
Even Gavin knows that - but apparently he prefers to have been spending the past two years of his life on developing an 'intelligent' fee discovery system and writing papers on why the blocks must be bigger.
And don't worry - he won't mind me saying it, I'm on his ignore list.
I can see why you might be on Gavin's ignore list.... your post has a very grumpy tinge to it. Getting onto your concerns, bitcoin is more than just mining. The users and people who build services are important too. Bitcoin is strong not because of some computers, but because of how, as a community, we use those computers. So it is in important to keep everyone together as much as possible. pitor_n, it sounds like you are speaking as if Gavin was proposing to create a MaxBlockSize when there was none before. If some miners started creating 3MB blocks right now, they would just be ignored. Why is that? Gavin's proposal is basically encouraging the network to give miners more freedom. The blocksizelimit was actually Satoshi's idea, to protect the network from attack. Satoshi's concept limited what miners could do, and Gavin is proposing to lift that limit, thereby giving miners more freedom. And you think Gavin is trying to control the miners? Do you think miners care what Satoshi's opinion was on the size of their blocks? Do you think miners care what other miners think about the size of their blocks? And what if some miners looked to Gavin as a leader in the community? I'm a miner, and for the moment, it matters to me what Gavin thinks. I read lots of opinions. I don't follow blindly. There is a negative incentive in mining too big blocks, as they propagate longer thus giving a higher chance of getting orphaned. You can try to lift the block size limit in the protocol, but even if the miners had allowed you to do it, they would still be limiting this very size, because of personal incentives - and that's all a developer needs to know about blocksize economics. |
|
|
|
|
The cruel thing about blockchain economics is that it's not for Gain, nor for any of his friends to decide about sizes of the blocks.
It's the mining, that he doesn't care of.
So I just wonder what is in this guy's head when he assumes that miners actually care about him and his opinion on a size of their blocks? Who is he actually speaking to with poems like this and what is a point of this?
People who understand the problem know that the key to make bitcoin really scalable and keeping transactions cheap is adding a layer of off-chain transactions on top of the existing protocol.
Even Gavin knows that - but apparently he prefers to have been spending the past two years of his life on developing an 'intelligent' fee discovery system and writing papers on why the blocks must be bigger.
And don't worry - he won't mind me saying it, I'm on his ignore list.
|
|
|
|
It is some sort of a mess that was created as the protocol was being developed. Now it has became a legacy... In general the bitcoin protocol uses most significant bit of an encoded integer value as the sign. I think the initial idea was that R and S values inside a signatures shall follow that rule - so if the highest bit happens to be one, it gets padded with a zero byte in front. Which obviously doesn't make any sense as these values are always positive and whoever was designing it had to know that. What's even weirder in here, the protocol doesn't follow the sign-bit-rule for the EC keys - these are also 256-bit numbers, but always assumed unsigned, despite of their MSB. And if that wasn't messy enough, the bitcoin protocol in general uses little-endian to encode integers - that includes 160 and 256 bit hashes wherever they are treated as big ints. It uses little endians everywhere, except for the values of EC signtures and EC keys. So the protocol is pretty much inconsistent, but you get to learn it after all  |
|
|
|
Why are the transactions stored in a hash/merkle tree ?
Why simply not store them sequential and calculate a single hash over all of them ?
Only reason I can think of is "more security" because of hash tree, more hashes to calculate...
When Merkle tree root is calculated, hash function is applied to fixed length data (32+32 bytes). Possibly, Satoshi considered some variant of length extension attack. Possibly, something went wrong I don't think the tree, as opposite to sequential hashing, adds any security. But it decreases number of steps you need to perform in order to recalculate the output hash value, when only one element is changing. If you're a miner and need to apply a new TX to a block - with the tree it can go faster. |
|
|
|
From what I see, a single check operation you need to do at the receiver side takes something like 1ms, for my optimized secp256k1 lib (it's generally faster than openssl). And that operations are on top of accessing the required transaction input data - note that to check past blocks, you need to dig inside the blocks db. For a real time blocks processing, there are blocks (e.g. #321848) where you'd need to perform tens of thousands of such ops - multiply it by 1ms and the number of scan-keys you'd want to monitor. Well you can make it in parallel, so divide it by two or three... Still IHMO, to make this method useful, we'd need to come out with some off-chain way of communicating which txs a wallet should check. Otherwise a user would need to have a pretty powerful dedicated server, to monitor stealth payments going into his wallet - java script client is totally out of the question here. And even having a powerful dedicated server, you won't be able to monitor thousands of stealth addresses on it - maybe a few hundreds at most. Moreover, re-scanning for an unspent outputs in the past blocks would be taking a lot of time. |
|
|
|
|
So basically the good thing is that stealth payments are indistinguishable and smaller, but the bad thing is that because of that you need to scan all the outputs looking for those belonging to a wallet.
Right?
|
|
|
|
|
I'm busy this week, but in general I'm into it and will gladly get to do it with my client.
Will be looking into this topic
|
|
|
|
|
I think you want to use secp256k1_ecmult_gen() followed by secp256k1_ge_set_gej()
The XY returned by the second function is the public key.
|
|
|
|
Having compatibility with a known schema has the advantage having additional security if the wallet development abruptly disappears or some bugs appear making temporary unusable the software.
It is also more flexible if I could use for ex. elektrum and combining sometimes with gocoin just generating the seed containing my coins.
For example armory is a little bit heavy but I can generate a tree quickly from my seed with a brainwallet(for ex. brainwallet.org supports it), receive payments on the generated tree addresses and later I could import the seed in armory.
A different, new schema could have sense if presents some advantages which balances the lack of compatibility.
I have the wallet's type in the config file (so far only 1,2 and 3 are used) and I can add other algos easily. I wouldn't mind adding new types (compatible with armory, electrum, or anything else), but the main problem is that none of it seems to be documented and there isn't really one established standard for it. The HD wallets might be a good way to go on with a standard, though they don't seem to cover the calculation of the initial vectors from the seed password. So it is an open topic and I think the software will eventually evolve to support other types of deterministic wallets, but I just don't want to add any new types without some strong user cases, because it would only create more mess. But the code is open and fairly simple, so if anyone wants to put in his own method, just play with the function make_wallet(), in file gocoin/wallet/wallet.go It is a dangerous place to play with, so feel free to post your changes here for an audit. |
|
|
|
Just a question.
The password-seeding uses a known algorithm like that from elektrum or armory or it is an own schema ?
Thanks.
The default type 3 is my own schema. It goes like this: seed_key = SHA256(SHA256(password)) /*the master seed*/
for n:=0; n<number_of_keys; n++ {
priv_key[n] = SHA256(SHA256(seed_key))
seed_key = append(seed_key, byte(n))
}
Type 1 and 2 are also my own schemas, though they use different algos. |
|
|
|
I used very simple passwords to generate the bitcoin addresses yeah, that's probably it. many easy keys have some bots, that capture money from them as it comes. as well as many stolen keys - such are definitely being monitored for a potential theft and robbed immediately as they receive any coins. |
|
|
|
|
it doesn't look like any error.
apparently, whoever knows the private key for 126zmC4XSu5nFU7bYZVwEn9iVc82MXk15B is running a service that automatically forwards all the incoming payments to another address.
your transaction is fine - the forwarding one is a separate transaction, composed and signed by someone else, not you.
|
|
|
|
Check out this tool: https://github.com/piotrnar/gocoin/blob/master/tools/bootdat_qt.goJust tell it where is the gocoin's folder with the blockchain.dat + blockchain.new files and it will create the bootstrap.dat (in the current dir). As for the memory consumption, I am aware of this issue. And that is why I have 12 GB on of RAM  I could try to tweak the garbage collector settings, but it will decrease performance in systems that have more memory. You can actually play with the settings yourself - it is "-g" command line switch. You can also try playing with "-m" and "-n". Although, if you need the downloader only to produce the bootstrap.dat later, just start it with "-b" - that should help. |
|
|
|
|
as for the downloader producing the files for the bitcoin core.
what I can do quite easily is to add a command to write the current gocoin's block database as the bootstrap.dat file.
though, I don't know how much it would help you, since importing bootstrap.dat into bitcoin-qt is also quite painful.
playing with bitcoin-qt's chain/wallet state databases is just too much hassle for me - I won't do it, sorry.
anyway, if anyone would find such a feature (creating bootstrap.dat) useful, just let me know and I will add it.
|
|
|
|
i'm asking if you can add to the downloader an function to select a different type of database. sure I can. the problem is that testing this would be very time consuming, so I am not very keen to start working on it, considering that it'd take lot of my time giving me back nothing I need myself. but I will keep your request in mind and see what I can do. cheers |
|
|
|
FYI, few days ago, after a longer period of testing, I released Gocoin version 1.0.0. I have built binaries of this release for Windows and Linux. You can download them from here: https://sourceforge.net/projects/gocoin/files/?source=directoryInside each archive there is a file with SHA-256 sums, signed with my bitcoin-otc PGP key. The Linux execs require 64 bit OS. Windows binaries require 64-bit platform for downloader in client, but the wallet and balio apps will also work on 32 bit systems. If you need a binary for any other platform (OSX, FreeBSD, Linux i386, Linux ARM), let me know - I can build it for you. When launching the client make sure to have the www/ folder in the place (it contains the WebUI app). For the wallet there is an example config file (with all the config parameters are commented out). Don't hesitate to give me a shout, if you'd experience any issues: tonikt@assets-otc.com |
|
|
|
|
Show Posts
