Bitcoin Forum
February 27, 2015, 07:32:57 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  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 ... 367 »
141  Bitcoin / Bitcoin Discussion / Re: BREAKING NEWS: Multiple Exchanges Affected - Possible Global Shutdown on: February 11, 2014, 09:31:12 PM
This is one reason why I don't store my bitcoins on exchanges or in other hosted wallets. I am completely unaffected. Hopefully this event will knock some sense into some people.

And while I'm on the subject ... sometime in the next few months, the wallet of some major site will be hacked and a bunch of people are going to lose all of there bitcoins. You heard it here first.

Wait, What?  Did something important happen?  I didn't notice.  My client says everything is fine.
142  Bitcoin / Development & Technical Discussion / Re: New Digital CB "band" for cryptosystems, i.e. offline bitcoin transactions on: February 11, 2014, 09:20:45 PM
Alternately, the PSK31 channels could be interlaced with the QPSK1000 channels, permitting 12 datagram channels and (with one PSK31 channel at the farthest 100 Hz on either side of each datagram channel) 24 live keyboard channels.  I doubt that a proper QPSK1000 signal is going to step on a full 2KHtz wide spectrum, but I rounded up the spaces so that they would fit well.  Interlacing would be a more efficient use of the spectrum anyway.
143  Bitcoin / Development & Technical Discussion / Re: New Digital CB "band" for cryptosystems, i.e. offline bitcoin transactions on: February 11, 2014, 09:11:14 PM
Thank you.  I expect that I'll be fleshing out a blockchain datacasting proposal as well in the near future, based upon Digital Radio Mondiale.  The idea being that disconnected nodes can listen for blockchain updates from any number of DRM broadcasters across the medium or shortwave bands (or even DRM+ channels in the FM band, if that ever happens) as well as broadcast both their own transactions to whomever may be listening.  The current purposal would also permit, with some modifications, an Electrum server within a 100 klick range to respond to requests.  It's extremely unlikely that the FCC would permit encrypted datagrams, but since no Bitcoin network objects require encryption as such, that should be okay.
144  Bitcoin / Development & Technical Discussion / New Digital CB "band" for cryptosystems, i.e. offline bitcoin transactions on: February 11, 2014, 08:43:35 PM
I've been thinking about this one for some time, and I have an early proposal that I'd like to flesh out with the brainiacs to see if there are any glaring errors that I've made, before I make a formal purposal to the FCC.  No, I'm not joking.

My proposal is to carve out a tiny 'band' about 12 kilohertz wide, centered at 27.095 Mhtz.  The radio heads will notice straight away that this is in the gap between channel #11 and #12 in the old Citizens' Band in the United States.  The reason there is such a gap there at all is because there is still a licensed remote controlled device frequency there.  I'm pretty sure that no serious remote controlled devices still use this frequency, since there are newer and more useful remote control bands in the 440 Mhz range.  If you have a device that uses this channel, it likely has one of those control pads with the huge pull out antenna.  If it has a "rubber ducky" antenna, or is shorter than 2 feet long, it's probably a 440 Mhz channeled device.

I propose that Quadrature Phase Shift Keying be employed, with forward error correction.  Between 27.089 Mhz and 27.091 Mhz would be as set of live "keyboard to keyboard" channels, each using a 100 Hz wide spectrum using transmission mode of PSK31 or QPSK31.  This yields 20 distinct channels within this 2 kilohertz wide band.  Transmittion powers would be limited to 1/2 watt peak envelope power in this section.

In the remaining 10kHtz wide section, between 27.091 and 27.101 would be a set of five 'datagram' channels wherein automatic rules based transmission and encoding would be required.  Each of these channels would be 2KHtz wide, and require the use of QPSK1000.  Within these channels, node to node or node to many broadcasts would be permitted; but a basic set of crash avoidance rules, similar to packet radio, would be expected of all players.  A single packet broadcast would be limited to 20 seconds, including preamble data and payload data, followed by a short postcode to let all other nodes know that the transmission is complete.  This should be large enough of a packet size that a normal sized transaction could fit into a single packet.  Other forms of datagrams would be permitted as well.  Peak Envelope Power in this section would be limited to 2 watts.  Packets do not require a destination node address, and any node listening that hears a datagram (such as a bitcoin transaction) can act upon that datagram depending upon it's configuration.  Alternatively, packets can contain gps directional information, and nodes would be permitted to "digipete" datagrams that it sees if it lays within 15% of the great circle path between the sender's gps code and the destination node's expected GPS code and/or the repeating node is within 100 kilometers of the destination node's expected GPS code.  This service would be "bursty" by design, and network protocols that require that content-less datagrams be broadcast (for the purpose of maintaining a virtual "circut" or persistant data connection, for example) are prohibited. 
145  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 11, 2014, 03:48:13 AM
You don't always need a missed block, but if you do, there are alternative paths to aquire missed data.

So, how do you know that you missed a needed block?


Oh, I'm sorry I missed this little tidbit.

The client knows when it's missing a block, because the headers are numbered as well as "chained".  It can tell immediately when it's missed a block.  How that can be handled, either automaticly or otherwise, would depend upon the user's situation.  Something like a Pskmail server, modded for Bitcoin, would work for the random user far from any urban area.  So would paying for a few megabytes over a sat phone.  Even a usb drive over a snailmail "sneakernet" (or, more likely for the regions discussed, a "motorcyclenet") would work great as a method to get a somewhat recent copy of the full blockchain into otherwise disconnected networks.  A single, modified client running on something like a piratebox could form the basis for bitcoin trades among patrons at a particular market.  If the client could receive a regular or on-going datacast stream of block-headers & merkle trees; it could verify that the network has accepted transactions that occured locally (since it already had those transactions) and learn about all other transactions from a regular full blockchain update via a monthly usb-drive delivery from a completely different source.  It could broadcast it's own locally discovered transactions to the rest of the network via PSKmail like shortwave connection once each day, by connecting to such a server 300 to 400 miles away (Near vertical incidental skywave, single hop) using a soundcard connected single-side band tranceiver (most common shortwave gear) pushing only 10 watts.
146  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 11, 2014, 03:15:51 AM
Without bi-directional communications, how do you get the missed block?


For an example of effective Internet access for the very patient, google the term "pskmail".  With bandwidths that are exponents of 31.25, (31.25,62.5,125,250,500 and 1000 Htz) and practial after-error-correction data rates that are very close to those numbers; the spectral efficiency of PSK on shortwave is very close to 1:1.  Which is excellent for anything that bounces off a kilometers thick refractor, normally called the ionosphere.  The range using relatively affordable equipment is uncontested at normal power levels.  Could this be used to datacast the blockchain? No.  Could this be used to broadcast locally generated transactions?  Yes.  Could this be used to broadcast requests for missed blocks?  Yes.
147  Bitcoin / Bitcoin Wallet for Android / Re: Should password really be compulsory? on: February 10, 2014, 10:23:16 PM
When the user of the Android Wallet wants to do a backup he has to give a password otherwise the application won't do the backup. Should the application really force the user to give a password? I mean one of the biggest security risks when it comes to losing bitcoins is in my opinion forgotten passwords. Why not make it optional.

Considering that Android Wallet operates in an "always on" networked environment, on an android device which is usually a smartphone, there is no other way to secure the wallet from malware.  An offline android wallet is possible, but pointless, and would still be exposed anytime the user desired to spend his bitcoins anyway.  So yes, the developers should force a password.  If you're stupid enough to make it too easy; well, you can't really fix stupid, but you can fix lazy.
148  Economy / Economics / Re: Peter Schiff on Bitcoin on: February 10, 2014, 06:53:53 PM
Another anti-bitcoin rant on todays show.  Will post later.  He keeps stating how newcomers to bitcoin will get discouraged by the sudden price drop and be completely turned off and never come back to it.  I hope he's wrong, but Peter is the man.

Some will, some won't.  That's no differnent than a rally in gold attracting newcomers who get burned on the correction.  Strangely, there are still people who don't abandon that barbaric relic.
149  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 09, 2014, 02:06:39 AM

Without bi-directional communications, how do you get the missed block?


You don't always need a missed block, but if you do, there are alternative paths to aquire missed data.  That's the advantage of a true p2p network, you're never dependent upon any particular peer for performance.  Datacasting the blockchain would reduce the bandwidth requirements of (potentially) thousands of clients within the practcial range of the datacaster.  That does not mean that it would eliminate the occasional need for a direct connection to the bitcoin network.
150  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 09, 2014, 02:02:07 AM
What you do is this.  Let's say the blockchain requires 2400 baud just as a constant stream.  Instead, you broadcast at some higher rate, say 4800 baud.  With the extra bandwidth, you re-broadcast the same thing, but delayed a bit.  So, with twice the bandwidth, each block gets transmitted twice.  If you miss it the first time, you have a chance of getting it the second.  With more bandwidth, you can add on more interesting schemes such that, eventually with enough throughput, it's possible to transmit the entire blockchain over and over again in pieces and if you listen long enough, you're guaranteed to get all of it.

Most datacasting protocols (for example, Digital Radio Mondiale) includes this delayed double transmission within it's protocol automaticly.  It's called "forward error correction".  While not perfect, it does work pretty well and actually doesn't require a full doubling of bandwidth.
151  Other / Beginners & Help / Re: Proof-of-stake cryptocurrencies comparison and vulnerabilities on: February 08, 2014, 03:20:20 AM
Well, I'm not a programmer, but I have been thinking about this one for a while.  I see a couple of problems with PoS that I have not seen addressed.  At all, not even poorly.  The big one is that PoS functionally creates "supernodes" in the major stakers willing to break their own anonimity to "forge" new blocks.  Bitcoin has no supernodes, because no node trusts another more than itself.  This is not possible with PoS, since the proof of stake itself is functionally used as evidence of trustworthiness.  The problem with this is that PoS also creates the condition that such a "supernode" can turn malicious, and cause great harm to the system.  Supporters would be quick to point out that anyone with a large stake would cause themselves great harm in doing so.  Well, yes, and that is my point.  The building of such trust in 'stakers' creates a perverse incentive for those same stakers to be compromised by a malicious third party, because the trust they have built up with the system becomes a method of causing harm to both the PoS currency system and the targeted staker in particular.  Or, alternatively, an incentive for a malicious hacker to figure out how to 'spoof' being a major staker. 

While hybrid PoW/PoS systems are not as subject to this effect as a pure PoS currency, hybrid systems still functionally promote the 'supernode' issue by creating nodes with a disproportionate ability to mine new blocks.  PoW doesn't have this problem, because no particular node can 'build' or 'develop' any special trust that lasts longer than the target interval.  Furthermore, hybrid systems are particularly complex, and may have other vectors of attack due to said complexity.  PoW is expensive from an energy perspective, as compared to PoS, but it's realtively simple and it works.
152  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 07, 2014, 04:29:13 AM
The Bitcoin blockchain can be kept up-to-date with less than a 2400 baud connection.  ... Or is this concept simply wildly-unrealistic, pie-in-the-sky speculation?

Maintaining the blockchain requires bi-directional communication.


This is not true.  Transacting with bitcoin requires bi-directional communications between transacting parties, but maintaining a local copy of the blockchain most certainly does not.

Quote

I could see the broadcast for the major part of the data, and your own internet connection to request missed blocks.


This would work also, but is not required per the light client protocol.  What has been proposed is to broadcast the blocks as they are published, and ultimately to broadcast the blocks "naked" once that protocol is ready.  The reason is that, eventually, most user clients will be some flavor of light client.  Unlike a full client, that are normal today, a light client doesn't care about all of the transactions in a block, and doesn't participate in the p2p bitcoin network (other than as an edge node, listening for it's own transactions).  A light client can fucntion just fine with occasional access to a bridge node (such as an electrum node) that can provide the light client information concerning transactions it's seen with addresses that the light client manages.  All that the light client requires is the blockchain headers and the merkel trees of block that contain input transactions for all of it's own addresses.  Broadcasting the published blocks would provide an alternative method for light clients to aquire the most recent block headers & merkle trees.  A light client may or may not keep the merkle trees for the blocks that it doesn't have input transactions, but as small as they are individually, the actual transactions are the bulk of data a full node sees while connected to the p2p network, and a light client has no use for most of these transactions.  Datacasting of naked blocks (block headers and merkle trees with all transactions pruned out) to either light clients directly or to disconnected bridge nodes used as intermediaries would permit bitcoin economies to function with only slow or occasional access to the Internet.
153  Economy / Goods / Re: Like Beef Jerky? (FREE Jerky) on: February 06, 2014, 10:45:37 PM
Begging is not, nor has it ever been, a cause for banning here.
154  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 06, 2014, 10:39:36 PM
From your link:

Quote
Sadly thus far, there has been little 3rd party driver support to include this.  Note that all of the newer Atheros Chipsets starting with the 9XXX series (The stuff that now is pushing 802.11n) has dropped XR mode.

I understand how it works.  What you don't seem to understand is that there is a reason it has been discontinued.  It's probably not a technical reason.

True.  I have no idea how many chipsets that might harbor a hidden support for XR mode might exist in the wild. 
155  Economy / Goods / Re: Like Beef Jerky? (FREE Jerky) on: February 06, 2014, 10:28:45 PM
he isnt claiming it isnt profit.

he says shoot to eat, not to sell.. basically.


Yes, and that was my point.  Shooting a deer to eat is still profit, and if you can shoot one to eat, why can't you shoot two to sell one?  Don't non-hunters deserve to eat also?  Hunting is a gainful hobby, when don't properly.  The idea that a hunter shouldn't be able to actually make a living doing so is rediculous, and only serves the interests of ranchers who raise meat animals in an enclosure rather than in the wild.
156  Alternate cryptocurrencies / Altcoin Discussion / Re: Ive just read that Ripple coin is centralised SO ITS a scam.True? on: February 05, 2014, 07:20:10 PM
There are two parts to Ripple. One part is a peer to peer credit system, within which any currency unit can be used.  The other part is Ripple, the currency.  It's not even a cryptocurrency, they are just digital tokens.  Yes, they are issued by a central authority, so Ripple (the currency) is centralized.  That doesn't mean that it's a scam, but I wouldn't use them personally.
157  Other / Politics & Society / Re: 2.5 M. to leave the work force by 2024 because of ACA, a positive thing says WH on: February 05, 2014, 02:11:27 PM
.....

2.5 Million Fewer Workers From ObamaCare A Small Part Of Economy:
http://youtu.be/Dmyd6aUDPwc
Less Is More!

War is Peace!
158  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 05, 2014, 02:09:56 PM
XR is not bullshitware.  I've seen it put into practice by hams.

http://www.qsl.net/kb9mwr/projects/wireless/modify.html

While these guys aren't to keen on it for their purposes, it does work somewhat.  Basicly the timing of transmissions are slowed down, to permit better low-signal copy.  A similar trick can be used with 100baseTX ethernet to extend the cable range limit between two bridge devices.  Your datarate is affected as well, which they admit.  Hams do something similar with very slow computer controlled morse code.

http://www.martellotowergroup.com/The_Martello_Tower_Group/QRSS.html
159  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 05, 2014, 05:49:14 AM


One of the other issues they have mentioned is that the 802.11 spec requires a minimum speed of 1 mbit.  So there is still a gap between what is clearly possible and what they claim to want to do.

Within official specs, yes.  However there is an extended range mode that is supported by some chipsets.

http://www.qsl.net/kb9mwr/projects/wireless/atheros_XR_whitepaper.pdf

I have no idea how common such support is for cell phones, but with a receive sensitivity of -107 db the loss of data rate might actually make this thing workable.
160  Bitcoin / Bitcoin Discussion / Re: Broadcasting the Blockchain on: February 04, 2014, 11:57:26 PM
but if the guy wanting to receive these datacasts has to buy or build dedicated gear to receive it, then what good is trying to do it using wifi standards and channels?  

I think using standard wifi gear (like an off the shelf usb dongle or a cellphone) is likely a pipe dream.  They were never really designed that kind of purpose.  Still there is merit in using the wifi frequency (and possibly channel structure) as it would drop the cost of mass producing customized receivers.  The chips that power wifi radios are dirt cheap because they are produced by the billions each year.    Hell you might get away with using a high gain antenna and a custom firmware flashed on a certain routers (think dd-wrt but for space based signal).


That's just the thing, if you have to get a dd-wrt and a directional antenna to receive it, why not just use DRM and shortwave receivers?  Again, datacasting is what DRM was designed for, and it uses a much more "efficient" schema in addition to the much narrower bandwidth (power) requirement.  Sure, it's data rate is slower, but like you said, that's physics.

Quote

The other advantage is that there is no license required.  5 Ghz might be a better choice though, I wonder if there is any data on comparisons between 2.4 Ghz and 5.0 Ghz over this type of link.


That's actually not true.  The license free ISM bands are only license free for terrestrial & incidental emitters, and every nation sets a pretty low transmission power limit.  The ISM license free argument, for a low earth orbit sat, fails on both counts.  They might get away with it, if they can get the sat up there and say "opps, sorry", but they won't get away with it if teh FCC gets wind of it.
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 ... 367 »
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!