I am excited to announce the launch of "Bridgewalker". After giving Instawallet into the capable hands of Paymium, I had some time to focus on this new project, which I believe is an important stepping stone in making Bitcoin more useful while it is still under the influence of the volatility of its small market. The basic idea is simple: Bridgewalker is a (hosted) Bitcoin wallet for Android smartphones, which allows you to receive and send bitcoins. So far, pretty standard. The difference is, that you will never hold bitcoins for more than a few seconds, as Bridgewalker will automatically exchange them for Euros as soon as you receive them (and they confirm) and will only buy bitcoins just that moment when you are about to send them. You can therefore use Bitcoin solely as a payment network, while being protected from market swings.  Get the app at: https://www.bridgewalkerapp.com/ ! A word about fees: You might assume that all that exchanging back and forth is prohibitively expensive. But it is actually not too bad (in my opinion), although there is certainly room for improvement. The fee for a "round trip" currently works out to around 1.5 %. Which means, if you send 1 BTC to Bridgewalker and then back right away, you are left with 0.985 BTC. This includes both exchange fees and losses through market spread (Bridgewalker currently uses Mt.Gox for currency exchange). The fees should go down though, as Bridgewalker's volume increases. One additional feature: Green addresses ( https://en.bitcoin.it/wiki/Green_address) make a comeback here. Bridgewalker accepts transactions from certain green addresses (at the moment only Mt.Gox) instantaneously and in turn sends out transactions that can be identified by the green address 1MAxx46Dp3tFw933PxPwEYYGCpxYda2pyH . Feedback and comments much appreciated! :-) Edit: Updated description to account for change of counter currency from USD to EUR (11/2013). Edit: Bridgewalker has been acquired by Hive! (11/2013). Edit: Bridgewalker is shutting down (03/2014). |
|
|
|
|
Impressive, very slick interface! One bit of feedback: It would be great to have a QR code below the deposit address. Makes it easier to use it in combination with smartphone wallets (using the website on a desktop, but paying with a phone).
|
|
|
|
|
rsoaDwv8M6UhNy3jCGfsgDJj8jBb5dtukM
|
|
|
|
|
Even better: Allow us to download a copy of the CSV file which is cryptographically signed by GLBSE. So we can prove to the issuers that the file is genuine.
|
|
|
|
|
Hey Garrett, any first thoughts on what to do regarding the whole GLBSE situation? Are you planning on continuing "on your own", if it (hopefully) will be possible to extract a list of share holders from GLBSE?
On the same note: Does anyone feel like panic selling? ;-) I was actually about to buy some COGNITIVE shares and would still be looking to get about 65, now at a price of 0.3 BTC each. Contact me, if you are interested. Escrow for both shares and BTC via Garrett (if he is fine with that), once that becomes somehow possible.
|
|
|
|
|
Hey! I have looked at Cognitive from time to time and have just been catching up. I have a few questions, that I couldn't answer from reading the thread:
What is the current MH/s of the mining farm?
Are the BFL Singles still hashing or are they already on their way back to BFL? (By the way, the OP still says that the Singles have not been delivered yet.)
Any contingency plan in case those new shares issued for acquiring Avalon ASICs are not actually sold on GLBSE anytime soon? I mean, it's almost $20k in new money needed there. And in the meantime those unsold shares kind of dilute the dividend payment, don't they? Or are you somehow redirecting the dividend payment for those unsold shares? (or does GLBSE already do that?)
Thanks in advance! :-)
|
|
|
|
Thanks for your criticism. One clarification regarding the problem of "constantly assigning funds to a long term online key which is potentially subject to theft": This reads like it might talk about the original technique? In this current proposal the marker address only holds a number of 0.01 BTC coins. But in general I totally see the problematic parts regarding privacy and increased store requirements - I even said as much in the paper. So I am all for specifying a proper out-of-band payment mechanism with all the bells and whistles one would like. But this is how I see it: Personally I think a decent solution for some type of instant transactions would open up the possibility for a whole new set of applications. On the other hand my impression is, that many people would disagree with this assessment and argue instead, that standard unconfirmed transactions are already good enough for anything one might want to do. Because of this, I fear that the development of a out-of-band payment mechanism focused on instant payments will proceed very slowly and have a hard time achieving enough participants. That's why I propose this as a stop-gap solution. It will hopefully prove that something like this is necessary and also make it clear in which situations it is typically used. With this information that a) there is a real need and b) a good understanding of the requirements, one can then go on and define a suitable out-of-band payment mechanism. Is there a risk that we are stuck with this forever? I don't know, I don't find that very likely. It's too much of a hack that one wouldn't jump at upgrading to something more elegant, in my opinion. So I am sorry to hear if some people consider it actively harmful, but at the moment I plan on continuing to push this. But I'm looking forward to participate and switch to any other better solution that is emerging. Does your sending code make sure that its inputs are very confirmed before it "signs" the transaction with its marker address?
It uses the standard algorithm that bitcoind uses to select coins. So it might select coins with as few as one confirmation, if I remember correctly. It would be possible to adjust that, if one wants to be extra careful. |
|
|
|
PaperI have summarized the ideas around green addresses (I decided to call them marker addresses going forward) in a paper which got accepted and will be presented at a Bitcoin workshop & tutorial organized by Professor Clemens Cap of the University of Rostock. The workshop will take place on September 20th. Paper: http://www.bitcoinmonitor.com/static/paper/marker-addresses.pdf Workshop website: http://bitcoin.uni-rostock.de/index.php?site=callforpapers_enMarker/Green addresses are a proposal for a simple method of allowing a Bitcoin sender to identify herself to a recipient, to be used in cases where two parties have a trust relationship and want to recognize each other's transactions for special treatment (usually instant confirmation). They have been discussed before on this forum primarily in these two threads: https://bitcointalk.org/index.php?topic=32818.0 https://bitcointalk.org/index.php?topic=48170Implementation: ReceivingSince finishing the paper, I have been working some more on the implementation side of things (based on bitcoind git tag v0.6.3). For the receiving side (recognizing marker addresses on incoming transactions) I have implemented an "getorigins" RPC call: https://github.com/javgh/bitcoin/tree/bw-getorigins ( diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-getorigins ) If you give getorigins a txid, it will (if the transaction has a suitable structure) display the addresses from where the coins came. For example for this transaction from Mt.Gox, where the green address feature was enabled, it returns this: ./bitcoind getorigins 162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a
{
"confirmations" : 39,
"blockhash" : "00000000000003cb80e379d5fae8e19c2594d35881ec21ff54847d99e6894671",
"blockindex" : 110,
"txid" : "162d25037687be593e1be27bf79583afa5141c7fcd168e068501f162d2016c9a",
"time" : 1344887758,
"origins" : [
"1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q"
]
}
You would then check if a known green/marker address appears somewhere in the list. Here we see 1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q, which is the green address currently used by Mt.Gox. In the case of Mt.Gox the whole transaction is funded from that address, but the way the paper describes the technique it might just be one of the addresses appearing in the list. Implementation: SendingThe sending part is still a little bit hacky. My code has a marker address hardcoded and expects that the local wallet has the necessary keys for it. It will then - Always try to add a single 0.01 BTC from that address to any outgoing transaction and an additional output sending it back. If this is not possible, the transaction creation will fail. It will resort to using marker coins with zero confirmations, if no others are available.
- Mark those incoming transactions to the marker address as change, so that they do not appear in "listtransactions".
- Prevent marker coins (coins at the marker address) from being used in any other way for a transaction, so that the marker address does not get depleted.
- Add an extra option to "getbalance", which shows the actual available balance after subtracting marker coins.
https://github.com/javgh/bitcoin/tree/bw-markeraddress (diff to v0.6.3: https://github.com/javgh/bitcoin/compare/bw-master...bw-markeraddressThe transaction http://blockchain.info/tx-index/15610835/5fcc25b576547aafddc1fed22d27259478d6c000540cb458df44c629eb10bd0b?show_adv=true is an example for a marker transaction created in this way. In this case the marker address is 1MAbwuYp8CPChJ1ua25tnEKXkfXTVqEoyg. Future workI am working on a new Bitcoin project which will also make use of marker addresses. I hope some nice demonstrations will come out of that, but that's still a couple of months off. Comments, questions and other feedback is appreciated! :-)
|
|
|
|
No, not "completely played off". This isn't a bank loan. I own the panels in full on day one.
It's not a loan, but the shareholders who gave you that money want something in return. And yes, by my logic, if cost of electricity is your largest problem... then lower the cost of electricity until its no longer a problem.
But solar isn't a way to lower your cost of electricity! Solar is a way to have a very predictable cost of electricity for the next 10-15 years. So again, I'm not disagreeing with you that solar might be a good idea. It is a good idea if electricity cost is going up and that seems likely. I would just like to see the cost of solar be correctly compared to other options. (And also not claim that it is an insurance against high difficulty - it's not, unless shareholders don't care that their initial investment is managed less than optimal by having solar equipment run on an inefficient process, instead of having it sell to the grid.) But it seems we are unable to find a common understanding. :-/ I guess we will have to agree to disagree. In any case: Good luck with the project! |
|
|
|
You misunderstood what I said. By trading bonds with me, you are cutting your dividend yield in half.
If I am only buying the bonds to trade them with you then no, I'm not really cutting my dividend yield in half. In the same way that when I buy an mp3 player to swap for a laptop, it's irrelevant what features the mp3 player has (and I subsequently "lost" access to). I only bought it because it was cheaper than buying the laptop outright. The people who are flipping cannot continually flip because it will drive bond prices up to unrealistic levels.
That's true. But just because this rebate can't go on forever, doesn't mean it's not a rebate. Once I own the panels, there is no continued cost of operation.
Only if by "own" you mean completely payed off. (Is that what you meant?) So in 10-15 years you have no continued cost of operation. By your logic a miner that becomes unprofitable could just go out and buy a solar panel and then say: Hey look, no continued cost of operation anymore, I can fire up my miners again. |
|
|
|
The market isn't very efficient here, sadly. The market is not factoring in the fact that I only pay out 50% of the bond dividends, the other 50% is going into the growth fund (which is now just buying more bonds).
The market isn't very efficient regarding what? The price of DMC? or the price of other mining bonds? It still doesn't change the fact, that you are giving a rebate to people who do a share swap. It's kind of a early adopter discount, which is fine I guess, except that it didn't apply to the very first buyers, who got in at 1 BTC. All those differences between DMC and other mining bonds are really not relevant, if you simply compare two situations with the exact same starting position: Namely starting out with 3 BTC and do either: a) buy 10x YABMC, then swap for 5x DMC b) buy 3x DMC at IPO price In both cases I had 3 BTC and afterwards I either have 5x DMC or 3x DMC, showing that the share swap gives a discount. (And since I started out and ended up with no other mining bonds, it's really not relevant what benefits they have or how they compare to DMC.) Its about 200 shares being sold by people who think they're flipping shares by trading me bonds and selling their shares at a slight premium. They cannot effectively do this without raising bond prices (although, for now, there IS a profit to be made). Existing investors, both those who bond traded and those who bought straight out, have been buying them as fast as possible because they see it as a good deal and want to take advantage of the flippers.
No, it's not a good deal to buy a share from a flipper. Only if you don't want to put in the effort to get the share swap discount yourself makes it sense to buy a share from someone who already did that, but then of course adds a premium for his 'work'. Cost efficiency isn't the issue. It already is efficient enough that it only takes 10-15 years to pay for itself in Maine. The problem is we have no fall back if mining becomes unprofitable: that insurance policy is a very important part of DMC, it is something we offer that no one else does; additionally, having that second revenue stream is also a very important part of DMC.
I have to disagree here as well. So much disagreeing today, sorry. ;-) But yes, I think cost efficiency is the issue. Solar isn't some magical way to make cheap energy - and you have pointed out as much, quoting a payback time of 10-15 years. So there is a guesstimated price to your own solar electricity and it's a rate which does not greatly differ from the rate you get from the electricity grid. So if mining becomes unprofitable, then you will also reach the point where it falls below your "internal" solar electricity rate at which point it is better to the sell the electricity back to the grid than waste it in an unprofitable mining process. That said, I don't necessarily think that it's a bad idea. Bitcoin mining is an ideal electricity consumer in the sense, that it can quickly scale down and back up to match supply. So it's a good fit for any fluctuating renewable energy source. And of course consuming your own electricity will usually be preferable to selling it back to the grid where you are paying middlemen and possibly other fees/overhead. So combining a solar farm with Bitcoin mining might give a unique advantage compared to other solar farms which just feed back into the grid and pay this overhead. I just want the economics of this clearly spelled out. |
|
|
|
Hey! Crazy project you have planned there, I like it! :-) Some people are viewing this premium as strictly "buy DMC for 2/3rds the cost", which is not entirely true. Up front, yes, you buy the DMC shares for that, but you give up two short term abilities: dividends (they are cut in half as per the 50% dividend/50% growth agreement in the contract), and the ability to sell (there is not a huge demand for DMC shares yet as the company is still new).
I'm not sure I can agree with this argumentation. The market should (in theory) have already factored all of these things into the price of the asset. If you are saying that 2x YABMC at 0.6 BTC (total) is really sort of equal to 1x DMC at 1 BTC after all things considered, then apparently the market disagrees or - since in this case the DMC price is just an arbitrary price set for the IPO - you have lowered the IPO price of your shares retroactively. That's not exactly fair to anyone who has bought shares at 1 BTC as they are now, as others have pointed out, in fact being diluted. Well, just my two cents. In any case, looking forward to see where this project is going! :-) |
|
|
|
Very cool to see this! I'm wondering, do you have some type of metal container you could use instead of the plastic one? That would do much more to dissipate the heat from the oil to the environment. Also helpful would be a larger mass of oil.
I don't have a metal one handy at the moment but yes, I might try that in the future. It might also help with the ooze stuff. Although: Definitely use a metal container with a larger volume.
I don't see why I should "definitely" use a larger volume. The setup produces zero invalids as it is already, so I don't really see the need for temperature related improvements. Or why did you suggest this? How long has that water been in there?
A couple of weeks now. But I did change the water once before, because I was also thinking that it might just be some oil that I spilled from when I was filling the inner container. I will change the water again a couple of times and see if the effect goes away over time, but at the moment it seems very consistent. Although I don't think it is anything biological. As you said, it doesn't really fit the consistency of the stuff. |
|
|
|
Hey there, quick update from the mineral oil cooling front. This is what my setup looks like now:  That board on the left is a Beagle Bone which I use to run MPBM (Beagle Bone + X6500 use 20 Watt in total). I wanted to get rid of the fan, but still keep the temperature down, so I added this water tank, which helps to dissipate the heat from the mineral oil container. This way I can even add a lid to the container and still have the heat dissipate quickly enough to have the FPGA stay at around 43 to 45 °C. The miner has been running without any problems so far. There have also not been any problems with oil running along cables or anything like that. Now, in my chemical newbness I haven't accounted for the following effect though, that I see in the water tank:   I'm not exactly sure what that stuff is, that is floating around the water. Is some of the mineral oil evaporating and then condensing again in the colder water? But it seems a little bit much for that, as I thought that mineral oil evaporation would be pretty minimal, from what I read. Or is the mineral oil attacking some of the container material? But why would it be on the outside then, where the water is, instead of on the inside of the mineral oil container? Does anyone have an idea what is going on here? |
|
|
|
I really want to thank Jan Vornberger, Instawallet's previous owner for being very available and responsive during the whole migration process, having thought of such a cool concept, providing me with loads of hand-crafted documentation, and more generally being awesome. He is a gentleman.
Thanks David! It's great to see Instawallet in capable hands. I wish you guys much success in your endeavors! :-) |
|
|
|
I see the site still shows "©2011 Jan Vornberger" and the e-mail address shown (presumably for support) is still jan's.
Where should requests for support be directed?
Davout & co. are still in the progress of transferring everything to a new server. While that is happening I am still mostly dealing with support requests. Once the transfer is complete, they will change the footer as well. |
|
|
|
I see...well I got them but man something crazy is going on over there. My account all of a sudden showed 80 coins, exactly DOUBLE what I had in there. Is that crazy or what? I wasn't sure what to do. Then the site shut down again. 40, the original amount came back and I sent it out. I still timed out and there was still no confirmation however it seemed to work.
Hey there. Sorry to hear that you had troubles with Instawallet, but it looks like it is resolved now. About the 80 coins showing up: This is a bug somewhere in the AJAX balance updater and only affects the display. The server side is correct and if you refresh the page you will always see the correct balance. I have yet to track down the bug, it might have something to do with having multiple tabs open of the site or something like that. I guess it's up to the Bitcoin Central team now to dig through my code base and track this down - poor guys! ;-) i just wish they keep the exact same settings as Jav had.
The site still runs on the same exact configuration as before. It just has continued to grow and the current server can't really keep up - sorry about all the inconveniences. Davout & co. are still in the progress of bringing everything up on a new server. From what I understand it will be a much beefier machine, so that should help. For what it's worth though, even under high load and frequent timeouts the site will never lose your money no matter what you do. Withdraws are always atomic. Either the transaction went out and you see the amount deducted, or both of it doesn't happen. Regardless of when an error/timeout occurs. Still, I know it can be scary to see an error message after a big transaction. So sorry again about that, and hopefully the work that Davout & co. are doing at the moment will improve the situation in the near future. Additionally, the site still shows the previous operator's e-mail address. So I posted an inquiry as to how to request support here:
At the moment I'm still mostly handling all the support requests until the server transfer is complete. |
|
|
|
Looking at the thermal data of the FPGA, I'd say that a heatsink temperature of 50°C and a board temperature of 60°C should be perfectly fine. 10°C more might cause invalids but shouldn't really hurt it. So as long as the oil stays around 50°C it should be fine.
Great, good to know. I now tried it without a fan for a day and the temperature has stabilized at around 51 °C. In that time it has produced 2 invalid shares (showing as 0.0%). You beat me to it, I just received my tech grade mineral oil yesterday and the rest of my parts should arrive by the end of the week.
Cool to hear that you are giving it a shot as well. Looking forward to see your finished setup! Awww you know that you will end up with oil on you desks? And u lost your warranty btw.  Good thing the X6500 doesn't have a warranty to begin with. =) It's called cappilar effect .... i did that once with my computer and the oil crawled up the mouse cable and after a short while my mouse began to bleed oil ...
Yes, I was wondering if capillary effect would be a problem. That's why I run the cables up the wall for a bit before going down again. I would think that the effect isn't strong enough to overcome that kind of distance. But only time will tell. I would think that in the case of a mouse cable the risk is higher, because by using the mouse, the cable is moved back and forth sometimes and helping in transporting oil where it shouldn't be. I think the situation here is much better, as everything is very static. |
|
|
|
I also wanted to point out a few things I ran into when setting up the software side of things, as it might be helpful to others as well. This is on Debian Linux: When I first connected the board using USB, I used 'lsusb' to see all connected devices and did a 'lsusb -v -d 0403:6001' to show more details about the board I just connected. That gave me some infos, but also a "Operation not permitted". To be able to access the board using my user account, I added this udev rule: /etc/udev/rules.d/90-fpgamining-x6500.rules with this contents: SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}="6001", MODE="0660", GROUP="fpgamining"
and created the group 'fpgamining' and added myself to it (you have to logout and login again for the change to show up): # addgroup --system fpgamining
# adduser jan fpgamining
MPBM still remained silent though and after I added some debug output about what exceptions are thrown, I got "could not set config 1: Device or resource busy". This, as I was quickly informed in the IRC channel, is because of the module "ftdi_sio" which is loaded automatically and grabs access to the device. So I did a 'rmmod ftdi_sio' and added "blacklist ftdi_sio" to /etc/modprobe.d/blacklist.conf to prevent the module from loading again in the future. After that it was smooth sailing with MPBM and this cool piece of hardware. =) |
|
|
|
|
Show Posts
