Bitcoin Forum
September 03, 2015, 02:30:16 AM *
News: New! Latest stable version of Bitcoin Core: 0.11.0 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 208 »
481  Bitcoin / Development & Technical Discussion / Re: Fastest, least-likely-to-be-subtly-broken way to make lots of addresses offline on: January 03, 2015, 05:22:40 PM
BIP32 hardened is perfectly acceptable to release private keys.  They're indistinguishable from random keys to anyone who doesn't know the master secret.  Fore BIP32 _non-hardened_ IT IS ABSOLUTELY NOT ACCEPTABLE TO PUBLISH THE PRIVATE KEYS. PUBLISHING ONE PRIVATE KEY IS EQUIVALENT TO PUBLISHING ALL OF THEM TO ANYONE WHO CAN GENERATE KEYS.
482  Bitcoin / Development & Technical Discussion / Re: bitcoinjs-lib and related repos are not 100% RFC6979 compliant (only 99.999...%) on: January 03, 2015, 04:23:35 PM
Okay, the r=0 (are there points on secp256k for x=0?) or s=0 is another (unlikely to occur) problem.
R.x == 0 is not a point on the curve; but R.x congruent to 0 (mod order) _is_ on the curve, and so r can be zero because r is the x value of R mod the curve order.

(And likewise, s can be zero; e.g. I have a test in libsecp256k1 for s==0:
https://github.com/bitcoin/secp256k1/commit/8d11164bc0e03024d38d5694e81f334ea31ec238#diff-4655d106bf03045a3a50beefc800db21R1210)
483  Bitcoin / Development & Technical Discussion / Re: Fastest, least-likely-to-be-subtly-broken way to make lots of addresses offline on: January 03, 2015, 02:24:02 AM
What risks are you concerned about?

Just incorrect key generation? Attempt signing with all the keys and verify the results. (Bitcoin core does this internally. And I strongly recommend it, it's a little terrifying that nothing else does. It's too easy to have a bitflip cause the creation of an invalid key, and too easy to defend against)

Poor RNG quality?  Thats harder. Vanitygen allows seperated (point addition) key generation, so you could e.g. generate one key another way and generate all additional ones as that key plus some new random value, in order to have a baseline expectation of security.

Concerned about side-channel (timing, emi, etc.) leakage?

Why is speed a concern? I can understand applications for generating some large number and putting them away... but if the keys are going into a safe what do you care if it takes an hour? How fast does it need to be?




484  Bitcoin / Development & Technical Discussion / MOVED: how to display bitcoin's key live data on an HTML webpage [bc.i] on: January 02, 2015, 07:44:26 PM
This topic has been moved to Service Discussion.

https://bitcointalk.org/index.php?topic=911309.0
485  Bitcoin / Development & Technical Discussion / Re: bitcoinjs-lib and related repos are not 100% RFC6979 compliant (only 99.999...%) on: January 02, 2015, 07:02:34 PM
Looking closer at the spec, it requires to use HMAC with the same hash that is used for hashing the message.
It does not.  In RFCs, requirements are usually specified using all-caps (though not strictly required), and special keywords. See RFC 2119.  It does make a suggestion to do so, but there are often good reasons not to do so; e.g. becuase of application layering, code availability, etc. (also RFC6979 is kind of embarrassingly slow already, mandating it be half again slower in our case would just encourage more people to do ill-formed adhoc things). In this case the suggestion doesn't even appear to be SHOULD level.

It's common for found-on-the-internet ECC crypto-implementations to be pedantically incorrect, and in worse ways than this. Caveat emptor. Virtually none of them that I've seen have evidence of strong peer review, or evidence that their authors have an especially detailed understanding of what they're doing. (Turns out you can implement working, or at least mostly working ECC just by aping some tutorials, which were themselves often written by people new to the subject).

I think being correct in this respect is important, not just in case someone manages to find the p=2^-256 inputs that expose misbehaviour, but also because the same code may later be reused for future curves where the field isn't so insanely close to 2^256, and a failure to implement this correctly can turn into a serious security vulnerability. It's also important to do right because it simplifies review: one can mechanically check each step and not resort to time consuming (and risky!) cryptographic reasoning about the implication of any particular change, the bug (or backdoor) that kills you is the one that looked harmless on the surface.
486  Bitcoin / Development & Technical Discussion / Re: Lightweight bitcoin relay node, how to setup. Does the network need it anyway? on: January 02, 2015, 06:59:48 PM
With this you mean a relay node without blockchain, right? (sorry for my noobness)
It's fine, yes. I mean a relay without a blockchain at all.  I think I misread your post as saying you had 1GB storage, but I'm guessing now that you have 1GB ram.

Soon-ish (probably in 0.11) we'll support running pruned nodes which could fully verify things but won't need the whole blockchain. They'll still require a couple gigs of storage and that amount will grow (but much slower, unless things that spam the utxo set become popular)... which might fit better on a small device like that, though it would be useful it wouldn't be as useful as something with the whole history.

Quote
So I can better attach a USB HDD and run a full node.
That you could do. Though right now you'll need, say, 60 gigs of storage though better if you have more since you'd be able to keep serving old blocks long into the future.  (Actual usage is more like 32GB at the moment, but since it can grow at a rate of about 25-50GB/yr, it's best to have plenty of headroom if you're going to store a full chain.

USB flash sticks often wear out quickly when there are many writes, so you'd want an actual SSD or spinning hard drive. On newegg it looks like one can get a 500GB usb external drive for under $50.

Quote
Are full nodes still useful for the network? Also when running on a low end machine (but 15Mbps bandwidth)?
I only want to run the node when it's really useful, otherwise it doesn't make sense.
Absolutely. One thing that would be pretty useful is to run a hidden service bitcoin node,  we're rather short on HS nodes and you can use tor to limit the bandwidth. ("BandwidthRate" in torrc).

The maximum long term average data rate for the blockchain is about 14kbit/sec. So even just a few megabits can do a lot to help keep more peers connected.
487  Bitcoin / Development & Technical Discussion / Re: Lightweight bitcoin relay node, how to setup. Does the network need it anyway? on: January 02, 2015, 06:08:32 PM
A relay node that doesn't filter for validity is not very useful for Bitcoin (and can easily be caused to get banned by all its other peers) and at worst is an attack amplifier.

It's great that you want to support the network, but running another node on that host is probably not the best way that you can do so right now.
488  Bitcoin / Development & Technical Discussion / MOVED: New/Custom RPC calls on: January 01, 2015, 06:11:15 PM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=909548.0
489  Bitcoin / Development & Technical Discussion / MOVED: Miner won't connect to pool on: January 01, 2015, 01:48:21 PM
This topic has been moved to Mining support.

https://bitcointalk.org/index.php?topic=910321.0
490  Alternate cryptocurrencies / Altcoin Discussion / Re: New/Custom RPC calls on: January 01, 2015, 12:31:51 PM
Ah, it's the standard game of trying to con the Bitcoin technical community into doing the engineering work for some competing altcoin which doesn't actually have any technical backing.

Thanks Shorena.
491  Bitcoin / Development & Technical Discussion / MOVED: Can you review this code and tell me if it would work? on: January 01, 2015, 12:28:08 PM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=910099.0
492  Bitcoin / Development & Technical Discussion / Re: fork detection behavior on: January 01, 2015, 06:55:50 AM
Of course, otherwise it would risk triggerable (or even spontaneous) convergence failures which could be exploited to cause loss of funds.
493  Alternate cryptocurrencies / Altcoin Discussion / Re: 1 wallet 1 account on: January 01, 2015, 06:31:38 AM
The first reason would be when a person/entity is owed a specific amount of bitcoin (measured in bitcoin) (either because they borrowed money, because they were provided goods/services or otherwise), but cannot pay the entire amount all at once
This does fit within the model of "address as an invoice number", and it's strictly less harmful than other kinds of reuse. Though it would certainly be possible to provide multiple addresses for this purpose (the payment protocol accommodates this, IIRC). There may be reasons why the receiver cannot handle funds split up, and so the willingness to accept multiple payments really should be established up front or no payment should be made.

Quote
Another reason to reuse an address would be to maintain the integrity of a charity
This application was my primary inspiration for the type-2 deterministic wallet proposal, which became BIP32: The FSF started accepting Bitcoin donations and they asked about being able to issue receipts for donation in order to comply with IRS requirements for 501(c)(3) chartable contributions over $250 in value. Doing so required they use one address per contribution but they did not want to generate private keys on an exposed web server which could be hacked.

Quote
If potential donors had to contact, say the American Red Cross every time they wanted to make a donation then the money would not make it to the Red Cross in the event their website gets hacked (and the hacker directs donors to send bitcoin to address that the hackers control).
Using an extended pubkey to receive funds allows the sender to verify the correct receiver statically without reusing addresses. Though this is not yet common.

Quote
I would argue that the benefits gained by using a single address in these scenarios (especially the latter) outweigh the drawbacks.
Considering that the donor's ability to deduct donations is lost completely for donations over $250 if the recipient cannot issue receipts, and in the US an organization accepting quid-pro-quo donations without issuing receipts (which they cannot do if they're reusing addresses) is in violation of the tax code and could be subject to fines, I question your cost/benefit analysis in that context. Smiley
494  Alternate cryptocurrencies / Altcoin Discussion / Re: New/Custom RPC calls on: January 01, 2015, 03:36:51 AM
I need help creating new RPC call list  that can give me the following information or if you know how to change/add a few lines that will provide the following results. (explicitly)

1) count of all incoming wallet tx - then all incoing wallet tx by account
2) count of all outgoing wallet tx  - then all outgoing tx by account
3) count of transactions to a specific address
5) total value of all incoming wallet tx
6) total of all outgoing wallet tx
7) count of mined blocks by this specific wallet
10) date of each accounts first tx
**note  i know of the existing call list and listtransactions, however it does not explicitly give these results.
As you note, these are indirectly accomplished via listtransactions already. It's not going to be faster to generate them directly as it will take the same process as a listtransaction to handle them internally.

Since you need help to do so, perhaps adding RPCs aren't the best way to handle your needs.

Keep in mind that errors made while programming here may cause funds loss. The threshold for where you need to add something new should be accordingly somewhat high.

Quote
4) count of transactions from a specific address
Bitcoin transactions do not have from addresses. https://iwilcox.me.uk/2014/no-from-address

Quote
8 )  total transactions in the entire blockchain
This data is in chainActive.Tip()->nChainTx

Quote
I have re-introduced IRC in my version of the wallet and wish to use it to automatically send payment requests (URIs), if anyone can help with that too  Smiley
IRC is a pretty crappy way to have a centralized server handle things... it's crappy because the server has few tools for DOS mitigation, because messages are very limited in size, and because it's frequently blocked.

If you're willing to trust a server to mediate communications, there are better options. Though, I won't if you really are willing... what happens when that IRC server replaces addresses in payment URIs?

Quote
Assistance is most appreciated.
You haven't actually asked a question. By assistance do you mean "I'd like someone to do the work for me, for free, and I'm not even going to tell you why"?  Thats what it sounds like, absent an actual specific question. If that isn't the impression you want to give you should try making it clear that you've attempted this stuff yourself already and ask specific questions.
495  Alternate cryptocurrencies / Altcoin Discussion / Re: 1 wallet 1 account on: January 01, 2015, 02:42:50 AM
Is this in response to my question? And did you read my reasons for wanting it that way?
I did, but it doesn't follow. One does not need to use a constant address to have transparency. (As an aside, your goal has extreme scaling problems if implemented directly; part of the reason to have exchanges in the first place is to support high volume instantaneous transactions.)
496  Alternate cryptocurrencies / Altcoin Discussion / Re: 1 wallet 1 account on: January 01, 2015, 02:34:06 AM
This is not good for security and it's also bad for not just your privacy but the privacy of everyone you transact with (and, ultimately) for all of Bitcoin. It also creates increased systemic risk for the system as parties that reuse addresses are trivially blockable and if many users are behaving in ways that can be blocked miners may be pressured to utilize their position in ordering transaction to block particular participants in the system, the same also applies to other services such as exchanges: if you behave in a identifiable way otherwise honest participants may be forced to block or seize your funds when they can.

Forcing a single address also generally incompatible with normal business practises. A Bitcoin address is emphatically not an "account"-- it's more like a serial number of a bill, alternatively it would be more accurate to think of it as an invoice number. Normal bitcoin usage requires you to use addresses to distinguish which of multiple payers has paid you.

For these reasons this behaviour is not generally supported by Bitcoin core and I question the level of understanding of the system of anyone who produces software which works in this manner.
497  Bitcoin / Mining support / MOVED: Merged Mining - ERROR: Aux POW missing chain merkle root in parent coinbase on: December 31, 2014, 03:47:47 PM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=909021.0
498  Bitcoin / Development & Technical Discussion / MOVED: extend the 21m bitcoin limit on: December 31, 2014, 11:06:17 AM
This topic has been moved to Altcoin Discussion.

https://bitcointalk.org/index.php?topic=908850.0
499  Bitcoin / Development & Technical Discussion / Re: could you be Satoshi - #1 did you learn about hashcash before bitcoin? on: December 29, 2014, 10:50:08 AM
Thats the point Adam is making. "Anyway I claim the hard part about bitcoin is the decentralised secure inflation control (and sybil resistant byzantine generals solution.) "
500  Bitcoin / Development & Technical Discussion / Re: Can block rewards be sent to a multisig address? on: December 28, 2014, 07:29:23 AM
If you include a multisig transaction in your block, can you have the block reward go to that address?
Sure. Any scriptPubKey works... in that respect its no different from any other transaction.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25] 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 208 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!