Bitcoin Forum
September 18, 2018, 06:27:16 PM *
News: Latest stable version of Bitcoin Core: 0.16.2  [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 76 77 78 79 80 81 82 83 ... 238 »
641  Bitcoin / Development & Technical Discussion / Re: Encrypt a message with bitcoin public key? on: November 09, 2015, 08:15:21 PM
Happy? Tongue
642  Bitcoin / Bitcoin Discussion / Re: BIP 0065 on: November 08, 2015, 07:57:05 PM
The merge is news, the release will be news. It's a darned interesting feature!
Old news, and there is nothing for people to do about it yet. Making noise about it now will only slow deployment, because you'll expend people's attention when there is no action for them to take. Smiley
643  Bitcoin / Bitcoin Discussion / Re: BIP 0065 on: November 08, 2015, 07:29:03 PM
Perhaps would have been more useful to hold off commenting on the merge until the release, which will be in a couple days.
644  Bitcoin / Development & Technical Discussion / Re: Encrypt a message with bitcoin public key? on: November 07, 2015, 06:27:14 PM
Now, you may want to send a message to the person whom you are sending bitcoins. Fortunately, this is possible now because of ECDSA system from cryptocurrency.
It is not-- a bitcoin address cannot be used for (asymmetric) encryption.  They could send you the related EC point as well, but since they must send you additional data in any case at the time they send you the address, they could just as well send a public key for a system specifically designed for message encryption.
645  Bitcoin / Development & Technical Discussion / Re: Encrypt a message with bitcoin public key? on: November 06, 2015, 11:04:48 PM
A bitcoin address is NOT a public key.
A bitcoin address absolutely IS a (serialization of a) public key,  it is a public key for the Bitcoin Script digital signature system. This system CANNOT be used for encryption, but signatures only.

If it were not a public key, you couldn't use it to identify the party authorized to release bitcoins. Smiley

The bitcoin address commits to, via hashing, an ECC public key, a cryptographic system used inside the Bitcoin digital system.  These keys could potentially be used for message encryption, if you were to get that EC public point somehow.

But then you need to ask the question _WHY_ you would want to do this?  It is usually strongly recommended that people not reuse the same keys for different application because the composite usage can result in insecurity. There are many pre-existing encryption systems which are competently constructed, and you could sign their public keys using a bitcoin signmessage.

Many of the "sign with bitcoin keys" things which have been constructed have been outright incompetent and insecure. So why would you not use standard tools but instead something novel and custom that probably has had no competent cryptographic review.\

The PGP keys use RSA instead of ECC, and RSA require much longer key size for the same security:
PGP now also supports ECC keys.

The security of the ECIES encryption is equally strong as the ECDSA that bitcoin use.
You would have to compute the discrete logarithm in order to break it.
This is not, pedantically, true.  ECIES requires a secure message authentication scheme, a secure message cipher, and a strong random number generator. If any of these (or their implementations) have weaknesses then you can compromise the confidentiality of encrypted messages without being able to find a discrete log.
646  Bitcoin / Development & Technical Discussion / Re: OP_XXX: How to take current block height? on: November 05, 2015, 06:40:11 PM
Will 0.11.2 have these OPs? Or they are only planned in future like sidechains OP?
Yes and yes.

It's a soft fork, like sidechains support. Its activation will begin shortly, with the releases of 0.11.2 and 0.10.4.
647  Bitcoin / Development & Technical Discussion / Re: OP_XXX: How to take current block height? on: November 05, 2015, 02:45:52 AM
I guess that will be once 0.12 is released.
Soft-forks shouldn't be and aren't tied to Bitcoin core major versions.  There will be 0.11.2 and 0.10. releases out with this in the next week or so.
648  Bitcoin / Development & Technical Discussion / Re: Running bitcoind in pruning mode on: November 04, 2015, 04:31:57 PM
You still verify and relay transactions. Other nodes can no longer get block from you though, at least for now.
If you run git master (to be 0.12 later) instead of 0.11 you will also relay new blocks as they are found while pruning.
649  Bitcoin / Development & Technical Discussion / Re: Synchronizing wallet balance from a pruned node on: November 01, 2015, 06:46:42 AM
Doing that invalidates the security provided by running it in the first place. (also I make no promises that someone can't elevate giving you database files into full remote code execution).

If you're willing to trust a source of the database why not just dump out the utxo database and just give people a feed of it?
650  Bitcoin / Development & Technical Discussion / Re: Synchronizing wallet balance from a pruned node on: October 31, 2015, 10:15:45 AM
if I didn't import enough watch-only addresses] and then use listunspent RPC.
So import a million, performance is acceptable with very large numbers of keys.

This sounds like you're asking about something for yourself to run.

Quote
Another issue is that currently pruning disables the Bitcoin Core wallet so
Mostly as a precaution as it hadn't been adequately tested.  It's enabled in master now and has been for a long time; considering the crazy things you were considering (concurrent access to the wallet database?!?) running master should be a no brainer.

If it would be useful to you, supporting rescan that goes back as far as the non-pruned data shouldn't be a big deal-- mostly an interface question of changing the rescan argument to take a depth and permit the import w/ rescan when the depth is compatible with the current level of pruning.  For what I think you're trying to do you really only need to rescan back a block or two, no?
651  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 29, 2015, 11:50:41 PM
Yes, I experienced corrupted wallet issue and I resolved it via -salvagewallet on a standard bitcoin core for windows. No, I never used any other utilities apart from the bitcoin core for linux and windows. I also did several rescans. This wallet has thousands of addresses and hundreds of thousands of transactions, its size is about 0.8Gb.
Great, may be a bug in salvagwallet where it's willing to add empty keys. I'll look into that...  potentially a result of the same reading code that accepts them at runtime.

Quote
Could you please compile a win64 or win32 binary for me?
Will do.  I'll let you know shortly. (Sent PM with a link to a binary)

Quote
Bitcoin core 0.9.3. doesn't have this feature? Check on private and public keys?
Correct, in versions before 0.10.0 (I think) we only checked the first key on decrypt. Later versions check all of them once per execution, as a result of PR#4670.
652  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 29, 2015, 06:36:03 PM
seen this. thanks. still, how it ended up in my wallet? with the private key in it? or it's just some fake private key?

Right your wallet has an encrypted key object in it with an empty pubkey.  It's not clear how this could have happened.  Has the wallet ever become corrupted, have you ever used any special wallet utilities on it?

In any case, the entry is meaningless and should be ignored.

Quote
yes, my wallet.dat is encrypted with a 128-bit password.

Right. The code path for non-encrypted keys checks the pubkey already; so I couldn't see how this was possible unless it was encrypted.

Can you try https://github.com/bitcoin/bitcoin/pull/6906 and see if it rejects this? If you're not compiling it for yourself, please tell me what OS you're running and I'll get a test binary for you.
 
Quote
At first, I was unable to unlock it with the latest version 0.11.1
Right, when it decrypts it checks that the private key and public keys agree, finds that they don't and then rejects the corrupted wallet.
653  Bitcoin / Development & Technical Discussion / Re: Ghost address 1HT7xU2Ngenf7D4yocz2SAcnNLW7rK8d4E appeared in my wallet.dat on: October 28, 2015, 09:09:33 PM
Is this wallet encrypted?

Would you be willing and/or able to test a patch?
654  Bitcoin / Alternative clients / Re: What is the best SPV for handling large number of users? on: October 28, 2015, 05:39:58 AM
Services providing services to other users should almost certainly not be using SPV.
655  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 27, 2015, 06:12:47 AM
They shouldn't be malleable; lack of canonicalization was an oversight.
Canonicalization is not sufficient to eliminate malleability; and some forms of malleability are very useful. intentional, features-- like the ability to construct anyone-can-pay transactions.
656  Economy / Services / Re: What is most best way to agree on something if all actors are known? on: October 27, 2015, 12:37:49 AM
When all the actors are known the problem you're trying to solve is called "distributed consensus" and there are many fine algorithms for it.
657  Bitcoin / Development & Technical Discussion / Re: tampering with bip70 payment requests on: October 27, 2015, 12:22:42 AM
The mechanism would be that you've transported it over a secure transport in the first place, e.g. HTTPS or encrypted email. No different than a Bitcoin address or plain payment URI.
658  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 26, 2015, 07:12:50 AM
How do you define toxic waste exactly ? Any usage which does not use bitcoin as value transfer ? how arbitrary is that ?
I wasn't even speaking about bitcoin. I was speaking about traditional toxic waste and your yard.  Smiley Uranium hexafluoride in alumnium cans, if we must name something specific... My point being that your argument was generic, "Using Nicolas Dorier's lawn for other purposes is not abuse if you are willing to pay the price".  Smiley

In any case, going back to Bitcoin, no one is obligated to relay or mine any particular transaction; and might not do so if they think they're harmful by whatever criteria they're using. One need not define anything.

But to your question of "arbitrary", do you intend to insult me?   I do not think it is arbitrary to say that Bitcoin, which was created, operated, maintained, and adopted with the express stated purpose of being an P2Pecash system ... has an intended purpose of being a P2P ecash system, and that use of that that is using the system outside of its stated purpose. By comparison there are alternative networks based on the Bitcoin code base which have stated purposes which explicitly include other things; and, as a point of history, when someone first proposed storing name registrations in the Bitcoin system the system's creator vigorously opposed this and recommended doing so in an alternative network.

Quote
That's sadly, the best impartial authority we can get, if you have a suggestion unbiased of personal view about what ought to be considered waste, I'm interested to know. (I'm talking solely about Blockchain use cases, not about technical decisions which help to keep properties of what make bitcoin unique)
Uses which are not related to Bitcoin ecash and instead just ride atop it as a communication/storage channel (or worse, try to explicitly compete with the Bitcoin currency and replace it in the market while using Bitcoin's own network) are a pretty good start.   Case in point, we're in a thread where someone was upset because nodes were blocking transactions of theirs which were creating purposefully unspendable txouts (e.g. adding non-Bitcoin bloat to the UTXO set) in order to run a commercial service called "crypto graffiti" which does what it says on the tin. I think that this is indisputable abusive: It benefits nothing but it's operator/users to the cost of every current and future user of Bitcoin, it uses the system not as an ecash system (which is what virtually all of its users signed up for), but as a messaging and free perpetual data storage layer,  this (data storage) usage potentially risks subjecting node operators to nuisances (e.g. DMCA notices), and even the name acknowledges its nature. ... but on the scale of abusive things it's not very interesting: something can be abusive without being worth worrying about, as the overall behavior of the system already confines the amount of damage to uninteresting levels.  It's only worth mentioning that it's abusive by way of explanation as to why I do not expect this kind of use to be reliable.
659  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 26, 2015, 04:42:52 AM
Using Bitcoin for other than monetary purpose is not abuse if you are willing to pay the price. (may it be either in fees or in dust)
You can't abuse Bitcoin anyway. Some tried, did not worked so much.
So, if I start accepting fees for it... people can leave toxic waste in your yard?  After all... they paid a fee.

Things are not so simple as you make them out to be. One user (drawn from a tiny subset of mostly a dozen people, currently) ... collects a fee then everyone else for all time in the future takes a bandwidth and storage cost.

Fees are a useful mechanism and, at times, an effective tool, but they do not themselves create moral authority or guarantee system survival because they do not and cannot pay the enormous externalities that dominate the system costs and they do not reflect a consensual interaction with all people they might impact.
660  Alternate cryptocurrencies / Altcoin Discussion / Re: Block lattice on: October 24, 2015, 08:30:15 PM
It appears (from the writeup) that you are unaware of sybil attacks?

The graph of transactions in bitcoin already functions like what you describe (except 'accounts' are single use txouts); Bram Cohen likes to call Bitcoin without the blockchain "bitpeso".  In Bitcoin the blockchain is overlaid on top of "bitpeso" to resolve "complex forks" (using your language) in a manner that allows someone to join the network and know which resolution is authoritative in a way which is both robust to sybil attacks and does not require membership (because a membership process would create control over the system).

In your description you appears to liberally conflate forks and double-spending.  In Bitcoin, double spending a traditional txout requires malicious behavior, just as you describe.  Blockchain forking in the absence of double spending is benign and no different to the "multiple resolution rounds" you mention from your resolution protocol but fail to describe detail sufficient to permit any analysis.
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 76 77 78 79 80 81 82 83 ... 238 »
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!