thanks
Is it possible to create a valid adress without the private key?
Yes, but it's practically impossible to find the private key for it. See - 1BitcoinEaterAddressDontSendf59kuESorry, I don't understand the mathematics. The BitcoineaterAdress - how was it created? Did someone created addresses to bruteforce the bitcoineater-public-adress? The address (before getting 58 encoded) is 25 bytes. First byte is always zero. Next 20 is the hash of a (hypothetical) public key. The remaining 4 bytes is a checksum of the previous 21. It's easy to brute force such strings to match a certain b58 text pattern. Much more complex though is to generate random private keys, originate a public key from that and hashing the public key - bruteforcing such to meet a pattern takes much more time. Yes, you can create a valid address without a private key, but you won't be able to spend from it. |
|
|
|
"the txids are in essence (indirectly) referencing"... - not "addresses", but specific coins; coins which are known to be unspent. in reality the blockchain protocol does not deal with such a thing as an "address" - instead it deals with a so called output scripts. "address" is just a concept that made the technology more user-friendly, but the block-chain itself operates on unspent coins (described by txid+vout) that are protected by output scripts. "to easily obtain the txids programatically?" check out this RPC command: |
|
|
|
Another monthly update on the development. The previous one was on 0.9.3 - now 0.9.7 is about to be released. Among the changes there isn't really anything big, rather gadgets though a few useful ones, so I think I will just quote the change log: 0.9.7
* Wallets tab of WebUI has an option to move an empty address to UNUSED wallet
* A user can quickly switch wallet being at any tab of the WebUI, as well as to reload it
* SendTx tab of WebUI refreshed Address Book using Ajax and addrs.xml
* Fixes and additional test cases around parsing of alert messages
* Added unit tests for "sighash.json" from the satoshi's repo and some more unit test rework
* A link to the user manual (served at google sites) in the header of each WebUI page
0.9.6 - 2014-04-02
* Client has a hammering protection (bans peers that keep trying to reconnect)
* Miners tab of WebUI does not show crap anymore is the chain isn't up do date.
* MakeTx tab of WebUI calculates estimated transaction size after signed (assumes compressed keys)
* Downloader can work with testnet and got a fix around an empty peers db after the headers stage
* New function "tools/utils/fetchtx.go", to download raw tx data from other websites
* If neccessary, FetchBal and FetchTx try several websites to fetch a raw transaction data
0.9.5 - 2014-03-24
* "MakeTx" tab of WebUI automatically recalculates the payment values to mBTC (for verification)
* The downloader does not have a default seed node anymore (you need to find one by youself)
* Do not block connections from 129.132.230.70-100 anymore
* Some changes in wallet's decode transaction functionality to better deal with non stardard txs
* "wallet -d <txfile.txt>" ignores spaces, tabs and EOLs in the hexdump of the transaction
0.9.4 - 2014-03-20
* The default "FeePerByte" changed from 10 to 1 (like they have done it in the reference client)
* The "-d" option of the wallet can now proparly decode coinbase transactions
* The client can work with multisig address description JSON files (place them in "wallet/multisig")
* Having the files in "wallet/multisig", MakeTx tab of client's WebUI can now create "multi2sign.txt"
... for the wallet, even properly mixing inputs from different addresses and address types.
* For multisig payments, "payment.zip" from the client contains "multi2sign.txt" and "multi_pay_cmd"
* The wallet can now deal with mixed (multisig and regular) inputs
Actually looking for the JSON files in "wallet/multisig" (added in 0.9.4) is a good stuff - quite convenient way of preparing multisig transactions for spending. If I'd only used it myself...  But if you are into multisig, have a look at this - you won't regret, I promise. From other things, there is an updated User Manual, which I have spent some time on today. I described the WebUI and the client's config file. I believe it covers now the most important things on how to use gocoin, but I am open for any suggestions. I mean, it's kind of hard to write a manual for something that you know everything about, because you built it. So if you had any questions that it doesn't cover, or some feedback about parts that are not clear, I'd be happy to address it. Also, apparently somebody reads this topic, because even though I wasn't asking for it the mods gave me back my Gocoin article on our wiki. So if you'd like to contribute into that article, feel free. Just don't delete it to replace it with your ads, please - this time I already know where to go  |
|
|
|
But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code. So, shame on you too! Check again; see the use of CKeyingMaterial/CPrivKey which uses a secure_allocator (which asks the operating system not to swap the memory to disk, and which zeros memory on free). If I recall correctly, the RPC importprivkey should be the only place where the normal memory allocator is used (the keys exist as ordinary hex strings in memory before they are processed by the importprivkey code). I see. Sorry - my bad. Shame on me, then! Well in such a case, the consequences of the vulnerability should not be so big after all, even if exploited. If the keys are not left there, on the heap, no attacker can get them. At the other hand to be really sure, one would need to dig into the actual openssl code, and audit that nowhere there such "secured" memory gets copied into some intermediate buffers. I mean, during any of the operations that involve some secret (priv key or a password). |
|
|
|
FWIW, I absolutely disagree with how the openssl team solved the heartbleed bug. Fist of all, the very issue of the problem originates not at this change, but at this one (or maybe even sooner, when they introduced an internal memory heap, to the library). "Memory saving patch" - really? This guy wrapped it up very well: http://article.gmane.org/gmane.os.openbsd.misc/211963Had they not introduced the own heap to openssl in the first place, this heartbleed bug would have been causing memory access violation and the issue would be spotted long ego. Moreover, the only reason for a security lib to have its own heap manager is to provide more security - meaning: make sure to clear all the memory while freeing it. What this heap does instead is actually making sure that no memory is being cleared, no matter how you had built the lib! So whatever buffer you allocate, in whatever function, there is a decent change that you will get it filled with some crucial data, like a private key used just a moment ago. And therefore, knowing life, I am pretty certain that there are also other functions that leak the private data from openssl's internal heap - its just a matter of time before someone finds them. The proper way to fix that issue was by fixing the internal heap (make it to clear the memory while being freed), or just removing it because it wasn't necessary in the first place. But definitively not just fixing it like this, abstracting from the actual original cause. At the other hand, it is a developer's (who uses this lib) duty to clear up all the crucial data from the memory, before freeing any buffer that would contain it, and preferably even sooner; as soon as the crucial data isn't needed anymore. But apparently only few developers actually do that and bitcoin core devels don't seem to be on that list... at last as far as I had checked this code. So, shame on you too! |
|
|
|
I would like to know how the wallet processes transactions and determines which transactions belong to me and which do not.
Yes, walletnotify fires when a tx related to me has changed and whatnot. But I would like to understand the back end a little more in the bitcoind.
Well man, it's a complex subject. Nobody can explain it to you in like one post. Had you have a specific question, that would be much easier. How the wallet processes transactions - that's the ultimate question, but there is no ultimate answer. Just a lot of studying. |
|
|
|
In case if anyone had wondered: No - Gocoin isn't anyhow vulnerable to the heartbleed attack. But mark my words: expect more of openssl shit hitting the fan in a future. And in the meantime: better watch your money - Gocoin can help you with this. |
|
|
|
So my implementation has not much to do with bitcoind, but instead it is focused on fulfilling my own personal needs, which might (by a chance) be similar with your needs
What do you mean ?
I said it below, in the same post: a possibility (though back then rather a limitation:)) to disable relying transactions, convenient cold wallets, network bandwidth usage limit. On top of that I can add: quickly switching between wallets, coin control (when bitcoind didn't have it back then), web interface (so I can operate/monitor my node via network), tuning to fastest peers (by periodically dropping the slowest one), mining pool stats... the list is long; whatever feature I found useful or even interesting during the last year - it's there. For me as a developer it is also very important to be able to quickly rebuild a software for trying any change - bitcoind is a nightmare when it comes to that. Go is just so much more convenient and its code much smaller and readable than C++, though still performing quite similar. |
|
|
|
executing pkscrip (from the output you're trying to spend) fails in EvalScript(), at this check: if (script.size() > 10000)
return false;
the pkscript from that coinbase transaction is almost 1MB - that's the reason, it makes it unspendable. |
|
|
|
blockchain info API is very easy to use, but I don't think it is secured enough - mtgox merchant API had a better security. I mean: except for the fact that the money was going into mtgox block hole anyway, the best API I can think of (which I don't think exists yet, at least not for free) should be based on public key cryptography validating the 'payment received' callbacks. blockchain info (for all I know) uses a fixed authentication token, same one for everything - that's just a disaster waiting to happen, if you'd want to use it for a serious stuff. |
|
|
|
Some are suggesting a mesh VHF network, but bandwidth on these frequencies, is too low.
I think you are either overestimating how much data bitcoin moves, or underestimating how much data packet radio can move. And you don't even need to broadcast the entire blocks to prevent a fork. Just announcing the block headers should be enough to inform the entire world where is the head of the chain. That you don't have the transactions - that would be a different issue. I was thinking about initial download of the block chain. That's eventually going to become a problem, even with the internet working just fine, outside a war scenario. Some way for compressing the chain (making possible to download just its current state) - this will become a necessity, sooner or later. |
|
|
|
You have "fd 04 a1", while it should be LSB: "fd a1 04" try this: 01000000010c0ff2174a66d60bc4316d6ceb07f4301bf076a8db2e887580
113e22ead8e62e00000000fda10400493046022100c9d96032febdad642b
e00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b05
46ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf0149
3046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb30
86bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771d
fc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642be002
84ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba
2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046
022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bc
bfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7e
f4d9456790fcb9af5ecf01493046022100c9d96032febdad642be00284dd
fe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f
7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf014930460221
00c9d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd7
56a774022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9
456790fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71
d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc4
54d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9
d96032febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a7
74022100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d94567
90fcb9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c4
2ee8b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d7
43a213ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d960
32febdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a77402
2100cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fc
b9af5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8
b1111cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a2
13ce7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032fe
bdad642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100
cc448b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af
5ecf01493046022100c9d96032febdad642be00284ddfe71d9c42ee8b111
1cecbb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce
7afd771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad
642be00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc44
8b0546ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf
01493046022100c9d96032febdad642be00284ddfe71d9c42ee8b1111cec
bb3086bcbfd756a774022100cc448b0546ba2a7f7fc454d743a213ce7afd
771dfc7ef4d9456790fcb9af5ecf01493046022100c9d96032febdad642b
e00284ddfe71d9c42ee8b1111cecbb3086bcbfd756a774022100cc448b05
46ba2a7f7fc454d743a213ce7afd771dfc7ef4d9456790fcb9af5ecf01ff
ffffff01d0dd0600000000001976a9147140b351f972295e98759a02c8f0
74bb7fd0c84b88ac00000000
|
|
|
|
|
I think the most important thing for me, is an easy to use cold storage wallet - deterministic, based on a seed password.
It does not require me to do any backups, not even to store the actual password anywhere, except in my own brain.
Of course, for convenience and additional security (to access the cold wallet less often), I also use a wallet containing some small amounts on the online machine - obviously with a different seed password, but also not requiring any backups.
The client node can switch between my different wallets, in a fraction of a second. So I can easily choose any of them, use the web GUI to make an unsigned transaction - and then just execute the wallet app (on any PC I want; hot or cold) to sign it, simply by typing in the seed password which I keep stored only in my head.
Let's face it: it's the best security there is and none of the existing commercial hardware wallets comes even close to it.
And the recent versions also support a relatively easy to use multisig signing - which makes the security aspects even more crazy.
Personally I have not used it yet, didn't find a need for it, but I did test it, FWIW, so it should work.
|
|
|
|
|
except that non-standard does not mean unredeemable
|
|
|
|
|
can you post the raw transaction here?
|
|
|
|
well, i think taxation plays a big role with regards to the acceptance of different governments. they don't want to legalize the use of bitcoins and they keep on giving negative feedback to it. that sucks for them |
|
|
|
what information do people who are **NOT** part of the address themselves see As long as you don't spend anything from a certain multisig address, everything stays secret from the third parties. As soon as you have spent anything from such an address, everybody gets to know: 1) How many signatures were needed (N) for how many keys (M) 2) Each of the M public keys |
|
|
|
Haven't really looked at the other project. From the description I read that it's basically bitcioind rewritten into Go - so that's at least the first difference, because Gocoin's architecture is quite different from bitcoind, especially at the "blockchain parser/db <=== online node ===> wallet" interface. Yes, it's been a year since I started it, so you may say that it was one man-year work, though I wasn't working on any schedule, rather for fun, education and a personal necessity. But that (according to some research I've learned) is supposedly much more efficient way of development than working for money and I think I can agree with it, comparing to how quickly I remember delivering stuff last time anyone was paying me, not to mention how much more stressful it had been So a may-year is a relative term and moreover, apparently the less you pay for it, the more you can get |
|
|
|
Ok I will explain again, I am a newbie and half the talk your saying is going past my head about a million k's. Im not a retard, but you need to explain things simply to I get it.
All I got out of that is that one transaction has already been spent, and you agree that why does it not show.
Your confused about the isvalid as much as me!
I have already said -scan did not work and I done it twice. It scanned, but never showed the missing payments. How on earth can you expect the world to take Bitcoin seriously if these problems cannot be understood even by well seasoned user?? The sad part is I am out of pocket here! I seriously cant believe you said it doesn't matter that much!!
Well, for a starter, I am saying that there is no fucking way that your bitcoin client (working in a non-testnet mode) would return: ... after validateaddress 1JJA3L6UGUtrK3MzscbKdWFt8mrv6eHfkk Either you found a bug in a piece of code that is very well tested (because completely wallet/chainstate independent) - or you cannot even execute a simple command properly. Not to offend you, but knowing life, my odds are on the later. In other words, paraphrasing you: how on earth can you expect anyone to take you seriously if the data you are providing are extremely hard to believe in? |
|
|
|
|
Show Posts
