Bitcoin Forum
May 11, 2024, 10:15:09 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 »
221  Bitcoin / Press / Re: 2012-09-17 crimecommission.gov.au - 2011-12 Annual Report (Investigations and Op on: November 08, 2012, 04:31:35 AM
The propaganda is heating up.

Before the masses will tolerate a crack down on our freedom they must first be exposed to this kind of BS.

Nice Find.

Thanks for the post.

"He who would trade freedom for security ends up loosing them both"



222  Bitcoin / Hardware wallets / Re: [ANN] Hardware wallet project on: November 06, 2012, 07:38:21 PM
Would have been nice if you made a post a few weeks ago.

I'm a few weeks away from having an actual PCB!
Do you have anyone working on a PCB?
Might as well group our efforts. Like you, it is meant to be open source.
We are all on the same team.


223  Bitcoin / Project Development / Re: Blockchain security tracking/colored coins/smart contracts - short python script on: October 15, 2012, 03:08:49 PM
There's a bounty available:
https://bitcointalk.org/index.php?topic=106373.msg1269388#msg1269388

I'm hoping the main group of people pushing for the development of this technology will
post a link to this bounty to inspire others to donate as well.

This is really great stuff and I'm very excited to see where it will go.
224  Bitcoin / Project Development / Re: colored bitcoins/distributed exchanges proof-of-concept on: October 13, 2012, 02:03:36 PM
There's so many threads and related topics to this stuff.

It is really fascinating and a huge step in the right direction IMO.

I want to throw a bounty out there for 2 BTC. Feel free to link to this post.

What is the bounty for? It's for a finalized protocol specification and description
of the entire colored coin and closely related concepts. It can be in the form of a wiki (I personally
prefer a PDF download). In order to claim my bounty, the spec' needs to become the primary
reference.

Those that have run off and started coding already are doing a great service of
verifying the concept in computer programming language, but at the same time are putting
the cart before the horse if they don't take the time to "hash" out the overall protocol
specification IMO.

Thanks to all your efforts.

225  Bitcoin / Bitcoin Discussion / Re: Hardware Bitcoin Wallet on: October 08, 2012, 04:12:13 AM
My Wife and a I were discussing the name tonight. Here's what we came up with:


Name: The BitSafe
Slogan: It's much more than a little-bit safe.
226  Bitcoin / Bitcoin Discussion / Re: Hardware Bitcoin Wallet on: October 07, 2012, 10:06:30 PM
I've been working on a Hardware Bitcoin Wallet for a few weeks now.

It's going to use MICROCHIP PIC32.
I was able to get ECDSA working and prove the concept on the hardware chosen, but the firmware/software is still seriously lacking.

In 6 to 8 weeks, I will have a prototype PCB.

Was going to wait to post, but since so many our focused on the same thing I don't want to duplicate the work.
It is going to be open source hardware and open source firmware/software.

However, I wanted to do it with one button. a quick press for one function and a long press (3 seconds) for a different function.

Also, I was looking for different ways to get away with not having a display to keep cost and size down. One thought was to have the
USB Security device to disconnect and reconnect as a keyboard and with a quick press - what is about to be signed would be displayed
with a signature (not the signature for the transaction), but from the USB device (to make sure its not some malware in between the user and the data that's being received).
If all is good, then a long button press produces the desired signature.

Anyways, please keep me informed if anyone else is working on this. I do have a PCB being designed and it's 20% complete.
Also have the design ready for a development board for those interested in developing the firmware and software. The will Start working on the PCB design after I build a prototype.
The final price looks to be between $12.00 to $15.00, but that is no guarantee and that may not even be conservative.
227  Bitcoin / Hardware wallets / Re: Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices on: October 07, 2012, 07:43:52 AM
So many great minds on here. I started working on the same project for the last few weeks knowing there had to be someone already doing the same thing.
Well, tonight I discovered this thread.

I'm not about making a profit or anything; I would just like to see this product available.

I've been coding for a MICROCHIP PIC 32 bit MCU.

228  Bitcoin / Bitcoin Discussion / Re: Fujitsu Cracks Next-Gen Cryptography Standard on: October 01, 2012, 06:10:37 PM
Thanks to the OP.

That was interesting.

Here's my Quick summary:
    They broke what is called Pairing Based Cryptography http://en.wikipedia.org/wiki/Pairing-based_cryptography
The press release from NICT can be found here:
http://www.nict.go.jp/en/press/2012/06/18en-1.html


Remember, we are using ECDSA and every public key is buried under the sha-256 hash and RIPEMD-160 hash.
As long as you never store value on a key that has already been used where ECDSA public is now known by all, you would be relatively safe.

If methods were found that made ECDSA significantly weaker, it would still be extremely difficult and very expensive if not impossible to steal from anyone that never reuses a key.

229  Bitcoin / Bitcoin Discussion / Re: Securing your savings wallet on: September 20, 2012, 10:54:02 PM
Hazek,
     I share all your concerns. I'm actively working on a Secure USB Bitcoin stick solution.
I'm currently in the feasibility stage. Trying to brush up on some programming skills to see if the microprocessor that only cost a few dollars will have the capability to generate signatures. If it does, then we are in business. It is going to be open source hardware/firmware.
230  Economy / Service Announcements / Re: Bitmit - Bitcoin shopping mall (Translators wanted) on: September 01, 2012, 06:49:21 AM
This is needed.
I often show the Bitmit site durring my presentation of Bitcoins to people in Japan.
It would be helpful if there was NOT porn on the front page.

Click on Settings, Miscellaneous, and uncheck "Show Adult Content".

Otherwise, stay logged out while demonstrating. If you are not logged in, it will not show Porn on the front page. But it will show it if you click on "Beauty & Health", "Erotic"



This stuff isn't censored. I always leave the box unchecked, but there is still stuff getting through.

231  Economy / Service Announcements / Re: Bitmit - Bitcoin shopping mall (Translators wanted) on: August 29, 2012, 07:56:41 PM
There's more porn and offending material that is not censored.

Is it possible to become a moderator for some of this stuff?
232  Economy / Economics / Re: BFL and Capacity Utilization: Jalapenos to Jump in Price? on: August 26, 2012, 06:07:42 PM
I don't think there will increase the price? Why? Because they seam to work very hard in being the best to discourage competition.
That does leave them with a dilemma though, if they cannot keep up with demand, it will be a great opportunity for a competitor to enter the market.

Also, they have a dilemma with the long term demand once everyone is upgraded.

It will be interesting to see how everything plays out.

My bet, is the wait times will just get very long and the secondary market for the devices will cost more.

233  Economy / Service Announcements / Re: Bitmit - Bitcoin shopping mall (Translators wanted) on: August 16, 2012, 02:16:54 PM
Tosaki ,

Would you consider helping merchants add small services to your web site?
There's a very small service I would like to get off the ground but it isn't worthy of creating a web page and all the other work required to get it moving.

It could be a good way to expand the site. I'm willing to be your first experiment if you would like try.
234  Bitcoin / Project Development / Re: Bitcoin's Decentralized PKI (Public Key Infrastructure) on: August 10, 2012, 12:11:35 AM
Update OP: 8/09/2012

Looking into the more technical aspect of how to store data on the block chain; so far, I've found these two methods:

1) Uses multiple outputs to send a message (store data). Each output address is data; therefore, the coins are destroyed.
https://en.bitcoin.it/wiki/Block_chain_message_service

2) Transaction with a message inside the script
https://en.bitcoin.it/wiki/Script#Transaction_with_a_message

Mike Hearn makes some good points about the first method that I believe also applies to second.
https://bitcointalk.org/index.php?topic=47283.msg607667#msg607667

Also, if I understand correctly, there are other ways to embed messages(data) into the transaction that are less likely to be (pruned) and deleted, but I'm still leaning towards #1.
Here's my reasoning:

* It requires more bitcoin to add data into the block chain when using the addresses in the outputs. Because of all the costs, it should satisfy any naysayer because the creator of the transaction "paid for it". Even if someone doesn't agree with the blockchain being utilized this way; well, who cares, those users burning their coins are making the rest of us more wealthy.

*When the question is asked "What uses does bitcoin have beyond just financial transactions?", you will now have an additional reason to give: pay miners to add data in the most distributed, secure, and accessible database in the world.

*Also, it would still be friendly to those that only want to manage a pruned/trimmed blockchain. As Michael Hearn pointed out, transaction outputs that will clearly never be spent can be deleted with no worry of anyone spending them.

I've also been thinking about adding in the technical document that all the coins used on undependable outputs for "Bitcoin's Distributed PKI" will be available for miner rewards once all the block rewards are finished. A new type of generation transaction could be created that would allow miners to collect those coins based on certain rules. This would give incentive to maintain all the unspendable outputs used in the PKI in the block chain database.
235  Economy / Service Discussion / Re: In support of genjix on: August 03, 2012, 04:41:53 PM
Let's stick with the Bomb analogy:

1) They knew it was a bomb. (By doing the security audit and from IRC chatlogs, etc.)
2) They accepted the bomb. (By signing the Bitcoinica limited partnership agreement.)
3) They announced they owned it. (https://bitcointalk.org/index.php?topic=77975.0)
4) They pretended it was not a bomb to the outside world to attract capital (http://bitcoinmedia.com/first-licensed-advanced-trading-platform-for-bitcoin/)
5) They did not defuse the bomb. (We were in a transition phase. We were planning to redevelop the platform at some point in the future. What could possibly go wrong!?)
6) The bomb blew up in their faces and wiped out all their customers. (Surprise!)
7) They pretended it was not their bomb. (We didn't finish the paperwork)
Cool They did not clean up the mess. In fact they made it worse.
9) Welcome to now.

Nice. That's one of the main faults I give the consultancy: they "took the bait". It was made so appealing! I can understand how they got suckered into to it.
They were trying to be very cautious on the deal, but at the same time didn't want to loose out. I'm sure they regret it.

On the "bomb analogy". What lit the fuse? In my opinion, it was Zhou's inability to be a team player. It just irked him to the extreme that he had to "see his baby" in their hands.
If Zhou was the hacker that cooked the books (rack space) and stole the money the second time (MT GOX), it would make perfect sense regarding his personality. He would rather see his baby burn consuming his "enemy" and gratifying his pride and ego at the same time. I know that type of personality all too well.
236  Bitcoin / Development & Technical Discussion / Re: Could blockchain compression/pruning lead Bitcoin to its demise? on: August 02, 2012, 05:55:50 PM
.......
In addition to that it's possible to retain strong confidence of trustworthyness in even in an environment where many people don't have access to the long ago historical data— I suggested an idea I call "proof of treachery" on the Bitcoin-dev list:

If the rules are violated in a chain someone who observes the violation can copy out the minimum necessary data to _PROVE_ that a violation happened (which is always small: it's no more than two conflicting transactions or one bad-signature transaction, and the hash trees that connect them to the header) they can then broadcast these proofs and any node— even one without the history can see and understand the proof just on a purely 'mathematical' basis— without trust and then completely reject any chain following the point of treachery, even if that point was long before the history they have.  Because information is hard to stifle so long as there was at least _one_ honest node that observed the cheating it would be reliably defeated.  That is not quite as good as "you checked for yourself", but Bitcoin doesn't quite achieve that even with access to the whole history because someone could have potentially concealed an alternative history from you (e.g. there is another longer chain but no one has told you about it) so Bitcoin's autonomy already depends on it being too hard to effectively conceal the truth from nodes for too long. Plus, a proof of treachery is much smaller and more easily passed than a block (and it's origin more easily concealed from someone who would want to suppress it).

That is a really cool. What's the chance of getting implemented? Are you still pushing for it?
237  Bitcoin / Development & Technical Discussion / Re: Could blockchain compression/pruning lead Bitcoin to its demise? on: August 02, 2012, 05:45:28 PM
Would this destroy Bitcoin? No, it would not;

If changes in usage resulted in centralization of validation it would 'destroy' Bitcoin. No, it wouldn't stop existing— but it would stop having a point. We have other ways to have centralized money and Bitcoin isn't an especially efficient one.

However…

Quote
I think it would be a huge loss. Why? Because the never-ending-supply of skeptics learning about Bitcoin can no longer trust solely in math and cryptography to audit the system. As soon as you start deleting information that is "no-longer useful" you have to start trusting the mining community that nothing dubious has been done though the probability of a mining conspiracy is extremely low;

Technology like pruning and txout trees are things which _prevent_ centralization. What you're saying above right now applies much more strongly to block validation then they do to storage.  Storage has been growing at a rate faster than moore's law and slow nearline storage is very inexpensive. At home I already have enough storage for about 100 years of the current maximum blockchain growth.  But timely validation is much more costly and there is a risk of a tragedy of the commons on performing it and everyone moving to centeralized webwallets or lite nodes that trust other nodes to be honest.  Technologies that minimize the cost of fully validating nodes are not a threat, they are potentially a salvation.

(In particular: it's already trivial to mine without having the history— all of these centralized pool miners are doing so already, and unless you're using P2Pool, bitpenny, eligius-gmp, or solo mining you are guilty of it too, so these improvements don't create new ways of being anti-social)

I'm not too worried about your concern because the cost of storage is reasonably cheap, and preservation of the data is valuable for many reasons and not just preserving the autonomous trust-freeness of the system— e.g. historical, contractual, investigative, and academic reasons. But the autonomous validation is probably enough incentive alone, after all the whole Bitcoin system was created in order to have that property.

In addition to that it's possible to retain strong confidence of trustworthyness in even in an environment where many people don't have access to the long ago historical data— I suggested an idea I call "proof of treachery" on the Bitcoin-dev list:

If the rules are violated in a chain someone who observes the violation can copy out the minimum necessary data to _PROVE_ that a violation happened (which is always small: it's no more than two conflicting transactions or one bad-signature transaction, and the hash trees that connect them to the header) they can then broadcast these proofs and any node— even one without the history can see and understand the proof just on a purely 'mathematical' basis— without trust and then completely reject any chain following the point of treachery, even if that point was long before the history they have.  Because information is hard to stifle so long as there was at least _one_ honest node that observed the cheating it would be reliably defeated.  That is not quite as good as "you checked for yourself", but Bitcoin doesn't quite achieve that even with access to the whole history because someone could have potentially concealed an alternative history from you (e.g. there is another longer chain but no one has told you about it) so Bitcoin's autonomy already depends on it being too hard to effectively conceal the truth from nodes for too long. Plus, a proof of treachery is much smaller and more easily passed than a block (and it's origin more easily concealed from someone who would want to suppress it).

So I think so long as we build all these paranoid little tools that preserve the vision of Bitcoin and act with thoughtfulness and care when making adjustments to improve scalability which might result in centralization then Bitcoin will do just fine.


Hi gmaxwell,
       Thanks for a great post. I have the tendency to think too much of the long term projection of this cool project and worry. I've thought some more about it and with your post I'm going to set my concerns aside and continue with the few projects I hope to realize.
238  Economy / Exchanges / Re: [ANN] Bitcoinica Consultancy abandons customers. Bitcoinica to enter Liquidation on: August 02, 2012, 03:59:09 AM
Tihan-
So, will you be requesting funds back from those who got paid out 100% of their claims so that everyone will get an equal proportion back?  And is it true that you had a hand in paying out 100% to a select group?

Please understand that I have no authority over the payout process past, present or future.

I'm only updating the community on the actions initiated by the investment group to move that process out of the hands of the Consultancy and into the hands of a legally appointed receiver.

Authority is one thing; strong influence is another.
239  Bitcoin / Development & Technical Discussion / Could blockchain compression/pruning lead Bitcoin to its demise? on: July 30, 2012, 06:03:45 AM
I can see how blockchain pruning and the "ultimate compression" would be very useful for many applications.
However, could it start a trend where no one, not even the miners, care about storing and maintaining the entire block chain when it scales to the same level as other payment processors?
It makes sense; why store and maintain it when "the next guy will take care of it if ever needed". Purchasing hard drives and spending money on the electricity to keep them running to maintain the entire block chain is money your mining competitor didn't spend.

It looks as if this trend will be set in motion and will make the entire block chain database heavily centralized or lost completely in the distant future. Would this destroy Bitcoin? No, it would not; however, I think it would be a huge loss. Why? Because the never-ending-supply of skeptics learning about Bitcoin can no longer trust solely in math and cryptography to audit the system. As soon as you start deleting information that is "no-longer useful" you have to start trusting the mining community that nothing dubious has been done though the probability of a mining conspiracy is extremely low; however, it is still a very valuable selling point for Bticoin that anyone can audit the system and have 100% assurance that all rules were followed to the letter. This can only be done with the full block chain.

So, how many of you serious miners feel the duty to maintain the entire block chain to increase decentralization and robustness of the system?
I, for one, have the goal of doing this, but will expect the costs to be recovered via transaction fees as the system scales. Am I alone on this? What percentage of the community feels this way?
Please chime in on your position/viewpoint


If I am alone, I need to rethink some of my projects I had for bitcoin. I'm hoping there's at least 50% plus.



240  Bitcoin / Bitcoin Discussion / Re: Statement about the suspect of recent Bitcoinica hack on: July 30, 2012, 02:59:15 AM

Justice is getting the money back, and extra at this point.


I respectfully disagree.  Not exactly sending the right message is it.    "Hey hackers, these jokers at the bitcointalk forum are pushovers!  Hack the shit out them (several times), but as long as you concoct some barely feasible story and hand back a portion of what you took, you get to keep the rest with no consequences!"

Yeah, awesome.

Exactly. Mybitcoin should've been the first and the last. I had no money in Bitcoinica (and I consider everyone who had to be naïve) but I strongly want Bitcoin to succeed. Thus, my motivation is in making sure scammers stop their bullying of my playground.



This tells a lot about your attitude. I hope it is a hindsight and you didn't assume Bitcoinica to be a scammer's product when it was launched.

I'm sure Bitcoinica itself has helped the community to grow (by providing a way to hedge and facilitate trading through the interest system), otherwise I wouldn't have been involved in the first place.

The community should encourage the creation of similar products with better security in place (especially crypto-based security, like segregated accounts).

Bitcoinica was great. The kid running it with a fragile ego wasn't great.
You sure showed those intersango guys that they weren't as good as you.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!