Bitcoin Forum
August 30, 2015, 05:51:44 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 ... 109 »
181  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 10:59:15 AM
Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.
It ties the implementation to openssl lib even more, making it harder (if not impossible) to remove openssl dependency in the future.
And openssl is a much bigger mess the bitcoin at the current stage.
Actually there is an easy solution for it.
There is a minimal version of openssl targetted specifically for low-power embedded devices: cyassl

You are obviously a low-level programmer, so stop wasting time on the forums and perhaps make Bitcoin compatibile with it.
182  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 10:56:14 AM
Since Bitcoin-Qt is already one big mess, with like almost 10 dependency libs, why not to turn it into even a bigger one, right?
Payment protocol does not increase the lib dependencies in bitcoin-qt/bitcoind. Have you looked at the implementation? it's pretty small.

Point taken, however this makes the possible ramifications even worse.
Because the implementation is so efficient and bloat-free, the risk of it becoming "standard" way of doing transactions in the future is even bigger.

So as I already wrote, 15 years from now it may not be possible to buy something using Bitcoin without trusting some CA, which are controlled by government.

But well, if using PKI stays optional, then I think I can live with that. Still, I hope most people will not be using this broken (as of today) functionality.
183  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 10:25:11 AM
Given that Bitcoin 0.1 had a payment protocol in it, and he ended up disabling it due to the lack of authentication allowing MITM attacks, I can only assume he'd be fine with bringing it back in a fixed form.
But there were several mentions of alternative ways to mitigate MITM problem in this very thread. Is none of them valid ? (I will cite the previous mentions from this thread):

- "Rivest's Interlock Protocol can prevent a man in the middle from altering your communications while allowing you to communicate at all.  At most, he is then reduced to an eavesdropper or able to engage a denial-of-service attack".
- "Bitcoin already has a solid public key infrastructure in that each and every coin is controlled by a public/private key pair.  If you know who owns a coin, you can compose a message to them and encrypt it using that coin's public key".
- "ZRTP: For people seeking trustless key exchange algorithm: it has been already invented (i.e. you can avoid MITM attack without relying on PKI) - ZRTP could be easily adapted to bitcoin payments, changing SAS authentication string to PIN , for example, as it can be only 16 bit number. However, you would have to trust the merchant not to scam you".

But at any rate, calling the PKI "centralised" vs Bitcoin "decentralised" is kind of amusing, given that there are more root CA's than mining pools.

1. This is not an excuse. Just because some part of Bitcoin is already centralized, should we make it even more centralized thus breaking it even more ? Where's the logic in that ?

2. There are decentralized pools (p2pool and such), just not many people are currently using it.
So mining is or at least *can be* decentralized.

----
Other than above, no more questions for now.
184  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 08:52:22 AM
Can somebody quote my questions, please ?

Gavin probably has me on his ignore list again. And i really want my questions answered.
185  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 22, 2013, 08:45:37 AM
@Gavin

I tried to be as constructive & reasonable as possible (and no shouting/emphasing/whatever).
I am getting any of my questions answered ?

Once again, the questions were:
Quote
1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?
186  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 11:44:38 PM
@Gavin Andresen

I'm not shouting anymore, but I am still humbly awaiting for your answers to my questions, please.

I am not in a hurry, however I am also afraid I won't receive them at all.
187  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 11:00:44 PM
@Gavin Andresen

Several questions:

1. In the post-NSA-snowden era, are you sure it is wise to participate in creation of a centralized mechanism, which governments can easily control ? Why would we trust *any* CA ?
2. What would Satoshi think of this ? Isn't adding a centralized stuff to a decentralized-by-design system kind of senseless ?
3. How do you think will the tinfoil-hatted-extremely-paranoid Bitcoin community react, when they realize you added a broken by design schema to the most important Bitcoin app ?
4. What problem exactly  are you trying to solve with this solution ? I don't see Bitpay, Inpay, Coinbase or others complain that they cannot do business using Bitcoin without this feature ?
Isn't the invoicing possible to do through third party app or in-browser using SSL ?
5. Why add such a non-critical feature to the core client ? Isn't it supposed to be as clean, fast and efficient as possible without unnecessary bloat ?
188  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 10:11:17 PM
SERIOUSLY, SHADOWOFHARBINGER:

I LOVE IT WHEN PEOPLE SHOUT AT ME! IT IS A GREAT WAY OF MAKING ME REALIZE THE FOLLY OF MY WAYS, GIVES ME WARM FUZZIES, AND MAKES ME WANT TO COME BACK TO THESE WONDERFUL FORUMS AGAIN AND AGAIN!

I'M GLAD YOU LOVE IT, I WORKED SO HARD ON IT !!!!!1111111oneone

----
But seriously, i do love to emphase important parts of my posts.
189  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 09:46:03 PM
SERIOUSLY, GUYS.

One question:

Devs, did you anticipate that in the future their new CA-Based centralized protocol may become the standard of doing Bitcoin payments ?
And then NSA/USA Govt/World govt/whatever can actually seize the CA and decide who can do business with whom ?

I guess that by the time I'm writing this, governments of the world already figured out that Bitcoin cannot be stopped using the easy "conventional" methods. So they may(or rather WILL) try to embrace, extend and extinguish Bitcoin. 1. First by making it centralized, 2. second by promoting the centralized way of doing transactions, 3. third attacking the single point of failure, thus ending it.

You are just in the process of helping them with the step 2.
190  Bitcoin / Development & Technical Discussion / Re: Invoices/Payments/Receipts proposal discussion on: October 21, 2013, 09:20:52 PM
I would prefer to pay with fiat than to sacrifice the privacy of my public keys, in all honesty. The trade off just isn't worth it.
Of course - who wouldn't?
What good would bitcoin be for, if you had to register yourself at a CA, before receiving any payment.
It totally contradicts the very principle behind bitcoin's existence.

+1000

Well, i never thought i would agree with you on something, but it just happened.

Adding any kind of "trusted" "root" servers to Bitcoin core totally negates the decentralized nature of the currency. What if in some time, everybody starts to build their buisness solutions of top of this OBVIOUSLY BROKEN centralized scheme and 20 years in the future Bitcoin will turn into another shit like central banks because certificate authorities will control who can and who can't do Bitcoin-related buisness ?

I tend to agree with the general concensus on the other thread running here somewhere: That this sort of functionality should be added as a vendor-neutral API interface, rather than being hard-coded into bitcoinQT, which should remain free of third party dependencies/support.
With full respect to the coredev team, this "upgrade" to bitcoinQT seems mostly like a solution without a problem, and not a really great one at that.

+ 1000

Adding "trusted" certificates of CENTRALIZED entities into Bitcoin code ? I mean *WTF* ?
191  Bitcoin / Development & Technical Discussion / Re: Proof of Storage to make distributed resource consumption costly. on: October 19, 2013, 11:23:30 PM
A proof of storage system:

Take some fast cryptographically strong pseudorandom function, e.g. like Blake2 or another hash function H().

The server gives the client a random seed and a target size. The client repeatedly applies H() in a tree, e.g.  {Left, Right} = H(seed) and so on, to build up the target size worth of data.  The client takes the final leaves of the tree and appends their index and sorts the data (or, equivalently, stores it in a binary search tree).

The server then can periodically pick a random index and perform log2(size) hash operations to determine the value at that index and then can challenge the client to provide the corresponding index for that value.

The tree structuring of the function means that you can cheaply lookup the value for a given index,  but looking up the index for a given value requires computing the whole thing (and storing it, if you want to efficiently perform multiple lookups).

I have just found time to read this post thoughtfully, and...
Mother of Hash... Another genius invention.

I mean how brilliant can the Bitcoin community be ? I am now convinced that most (if not all) of current humanity's problems can be solved by genius mathematical algorithms.

PS.
I wonder if this couldn't somehow be used in file sharing by the way ?
192  Bitcoin / Press / Re: 2013-10-17 Register: How mystery DDoSers tried to take down Bitcoin exchange on: October 17, 2013, 09:05:34 PM
Is there a TCP/IP alternative that's resistant, or more uneconomic, to use for DOS attacks? This whole progression of having firms that specialise in DOS mitigation looks more and more like a protection racket business model. I understand that the Linux kernel was both designed and improved to negate the use of virus protection on the platform, despite not succeeding in elimintaing Linux viruses altogether. A similar outcome with a TCP/IP usurper would be most welcome.
Nothing except specialized services can protect you from 100Gbps attack if your normal connection is only 1Gbps.

It simply overfloods the pipe - it works in the same manner as water. When attackers use up all your bandwidth, nothing is left for the normal traffic.
193  Other / Politics & Society / Re: Capital control in action, does cyprus ring a bell on: October 17, 2013, 12:17:21 PM
Yesterday I got a letter from my bank (German bank) telling me they would reduce the amount I can send from 25000€ to 5000€. My gf who is at another bank for her limit reduced to 2000€ 2-3 weeks ago. They they one can manually increase it by calling them but this increase is only a temporary thing then.... idk what to think about it =/
This may be some serious shit.
I am pushing this to another forum.

© 2013 JPMorgan Chase & Co.
Hm, the name rings a bell BTW.

If they are making moves like this, something may be in the air.
194  Bitcoin / Press / Re: 2013-10-13 CNBC - "You can't stop bitcoins .... like you can't stop gunpowder" on: October 14, 2013, 08:00:38 AM
As much as I would like intellectual property to be protected
There is no such thing as "intellectual property".

It is an artificial theoretical creation by the rich and powerful to keep their monopoly, thwart progress, establish censorship and make poor people poorer and unhappy.

----
I just LOVE this McAffee guy (though he may be little crazy).
195  Bitcoin / Bitcoin Discussion / Re: Should miners collude to steal funds from wallet confiscated by US government? on: October 13, 2013, 09:36:22 AM
We should really give "idiot of the year" badges to everybody who voted "Yes" and the topic author.

It would be so much easier to populate ignore lists later without wasting time for discussion.
196  Bitcoin / Bitcoin Discussion / Re: Do you see Silk Road's closure as a positive or negative? on: October 12, 2013, 03:24:39 PM
Positive, but not because of closing of Silkroad itself.

The guy who was running it was an idiot, a total asshole and a hardcore criminal (he attempted to assasinate somebody). He deserved everything that came his way.

I'm only sorry for some of the poor dealers who are simply delivering goods that people want, I see nothing wrong with this.
197  Bitcoin / Development & Technical Discussion / Re: [UPDATE] Bitcoin client soft-fork "No Forced TX Fee" v0.8.5 avaiable on: October 07, 2013, 07:38:21 PM
2013-10-07 Update:

NFTF - versions 0.8.4, 0.8.5 released.

Fresh tag - nftf-v0.8.4, nftf-v0.8.5 is avaiable for download.
https://github.com/ShadowOfHarbringer/bitcoin-nftf/tags

MASTER branch was also updated to latest Bitcoin version:
https://github.com/ShadowOfHarbringer/bitcoin-nftf

EDIT: Sorry, mistake. I did not update master this time.
198  Bitcoin / Development & Technical Discussion / Re: bitcoins with homomorphic value (validatable but encrypted) on: October 07, 2013, 02:45:52 PM
Correct me if I am wrong here, please.
You are wrong. But you're asking in the wrong place— go see the nice article on wikipedia.
I did see the article on wikipedia, and it says that full homomorphic encryption is a scientists' wet dream and it has never been achieved.

Well technically it was achieved by Gentry and a few related improvements on that, however those schemes are extremely far from practical.
So for practical usage it has not yet been really achieved. That's what i wanted to say.

Anyway, it would be extremely cool to have homomorphic encryption as it would enable ultimate blockchain compression (there was a topic here claiming that).
199  Bitcoin / Development & Technical Discussion / Re: bitcoins with homomorphic value (validatable but encrypted) on: October 07, 2013, 07:24:47 AM
Correct me if I am wrong here, please.
You are wrong. But you're asking in the wrong place— go see the nice article on wikipedia.
I did see the article on wikipedia, and it says that full homomorphic encryption is a scientists' wet dream and it has never been achieved.
200  Bitcoin / Bitcoin Discussion / Re: Should miners collude to steal funds from wallet confiscated by US government? on: October 07, 2013, 06:20:00 AM
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 ... 109 »
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!