Ok, I understand that a lot of thought has been put into this, but out of experience I can say that when many very complex solutions arise to one problem, it's often the problem that is the problem. There is no transaction system in the world that is secure, it's not mathematically possible. And adding steps to render transactions more secure/cumbersome can be done outside of the bitcoin solution, outside of the computer even, it doesn't need to be integrated into the protocol.
I would still recommend implementing a lighter transaction system that can scale, not a complex one that solves a problem nobody needs solved.
|
|
|
Ok, to me this seems like over engineering hell. You are trying to implement a really complex system to solve something you can't solve. Namely the: "guns don't kill people, people kill people" all over again. I humbly suggest the attention be put to scale the bitcoin transaction system instead, security can be handled by external solutions/third parties.
|
|
|
I don't understand how a 2 phase commit will improve security when one of the phases will only practically be controlled by the attaker?
So say you go to the store and buy a snickers. Today you verify amount of BTC and destination address then send the money. The store sees the payment (one destination address per register) and lets you exit the store.
With these BIPS the only change is that the guy behind the register has to press an ACCEPT button right?
Am I understanding this correctly?
|
|
|
ztex said he expected these to run 5 - 10 years... I guess depending on heat?
|
|
|
Ok, anyways my revenue has increased more than expected with this version, so heat or no heat it's working great; and it seems you fixed my previous network error speed reduction too so: thumbs up!
|
|
|
Just try to use your ARM linux as a workstation with java, eclipse, chrome WITH flash support and spotify, skype, wine etc. If you wan't to do anything else in your life you won't be able to.
|
|
|
Yep, mine is running at 216 MHz... It's really cool too... I wonder why? Why does the error rate rise at 220 when the chip doesn't generate any comparable heat to the last firmware at 208?!
|
|
|
the d2 works fine for me with zalman heatsink stabilizing around 208 MH/s at 210 MHz:
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.10%, maxErrorRate=0.69%, \ hash rate: 209.8MH/s, submitted 2 new nonces, submitted hash rate 208.5MH/s ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.08%, maxErrorRate=0.69%, \ hash rate: 209.8MH/s, submitted 3 new nonces, submitted hash rate 208.6MH/s ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.28%, maxErrorRate=0.69%, \ hash rate: 209.4MH/s, submitted 0 new nonces, submitted hash rate 208.5MH/s ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz, errorRate=0.21%, maxErrorRate=0.69%, \ hash rate: 209.6MH/s, submitted 3 new nonces, submitted hash rate 208.6MH/s
|
|
|
Don't forget the new firmware: -f ztex_ufm1_15d2.ihx
|
|
|
Im talking total power draw measured using a kill-a-watt. You figure in the ineffeciency of the PSU, HDD, and the mobo, you will see around 50 watts.
No, the processor draws 13W for the one I have and 10W for the next generation. If you compare that to the ztex FPGA 8W it's really ok. The peripherals will draw on any other card too. And the linux you get on any non x86 architecture has NO software support. The choice is easy!
|
|
|
I use a mini-itx atom D510MO as desktop and run my fpga from that, economical, silent and better for the environment and with proper linux!
|
|
|
D&T are you using p2pool? What would you say of the payout compared to say deepbit?
|
|
|
How do you change your authorization pin?
|
|
|
But p2pool might be an important step for bitcoin so that makes it a bit more interesting!
|
|
|
en pool med escrow tjanst sa att man kan borja handla fysiska grejjor (inklusive SEK) for BTC utan risk genom bitcoin.se.
|
|
|
I think p2pool needs long polling, I asked SZ about a deadline and he said jan/feb.
|
|
|
I still contend a ASIC SHA256 implementation would be the way to go. Have a bunch of pairs of these, a few buffers, an FPGA controller and you're golden. Yes, from what I gather ASIC performance is not that much higher than FPGA per chip, it's power consumption that drops a little but mainly the price, so you could have lots of SHA256 chips cooperating. The tricky part is to build that cooperation hardware/software I guess.
|
|
|
I'm in Switzerland. At 2 to 3$ there was almost no gain with GPU for me. Now @ 7$ it's a different story but i like to try out new things. It's not about max gain. It's a(n) (expensive) hobby. Still waiting for BFLs product. But their power usage was a big disappointment for me. This boards are twice as efficient compared to the first tests. Ok, I agree with that! But I realize that if you have heating needs; GPU is the way to go. Although you build up a "dependency" on electricity for heating which is bad. I'm in Sweden so electricity is ~0.12$/KWh and I should be GPU mining, but I like the silence and the small size!
|
|
|
|