Bitcoin Forum
June 25, 2024, 06:02:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Economy / Goods / Re: Ammo 7.62x39 on: March 19, 2013, 06:58:51 PM
Probably because that same pending legislation has driven up the price. If you have more than you need then why not share the love before it is too late?
2  Bitcoin / Bitcoin Discussion / Re: Bitcoin-Qt/bitcoind version 0.8.1 available on: March 19, 2013, 06:13:18 AM
0.8.1 is there but SF still claims 0.8.0 is the latest version.
3  Alternate cryptocurrencies / Altcoin Discussion / Re: BTC is useless now. on: March 19, 2013, 01:57:17 AM
Litecoin is a little faster today but not tomorrow. Litecoin was made because people had sour grapes about the mining power required for BTC. The CPU users are still burned already and the GPU users just want their rigs to give them more life. But ASIC mining is a much better answer for the currency.

When litecoin is up to the popularity and lifespan of Bitcoin it will be equally slow if not more so because it intentionally blocks super fast ASIC mining.
4  Alternate cryptocurrencies / Altcoin Discussion / Re: Bitcoin Superset? on: March 19, 2013, 01:52:34 AM
I was thinking of a decentralized peer to peer project not a for profit. The whole thing doesn't work without the escrow.

For starters as far as I can tell ripple has a fixed amount of it's currency and it is permanently consumed through usage. So the project has a fixed point of death. The parent company is retaining a large amount of the currency.

In all the talk of chains of trust on the website there isn't a single world that mentions something actually changing hands. If I trust pointA and you trust pointB and they both trust point C... how exactly does that magically get dollars you have in your bank account but point A doesn't to me? How are you even supposed to get it to pointB and they to point A or is point A expected to be a large central reserve of funds that is supposed to trust B even though they really don't trust you, B or me? Trusting someone doesn't equate to trusting who they trust.

1. Trust someone who trust someone you don't trust
2. Huh
3. Profit

Even if it were clear. I don't trust people. Or rather what I trust about people is their unreliability. I trust probabilities. Bitcoin doesn't merely work because people believe in it, people believe in Bitcoin because pretty much every aspect has a solid numerical basis.  People statistically being more likely to hold up a deal they solicited when there is an upside they wanted and no upside to failing to follow through. That just makes far more sense to me than a magical cloud of trustberries.
5  Alternate cryptocurrencies / Altcoin Discussion / Bitcoin Superset? on: March 18, 2013, 08:23:15 PM

I was sitting and looking at Ripple today and dislike it for a number of reasons. Thinking about how I'd solve that problem I had some thoughts and wanted to solicit feedback and inquire if anybody is looking at doing something like I came up with (am coming up with).

My thought is essentially another decentralized network but a P2P trade network. This would have a simple API that would among other possibilities allow merchants to accept a Bitcoin payment from a customer and immediately generate a sell order for a desired alternative currency be it USD, EUR, Gold, whatever.

The network would need a few critical pieces:

* Alternative currency options to choose from.
* Escrow and Escrow time limits related to the above
* Buyers and Sellers (obviously)
* Shared Order and Escrow Ledger
* Huh
* Profit

The alternative currency options wouldn't be strictly currencies. They would represent accepted payment methods, they would have properties like transaction size caps, required escrow terms, and necessary receiver data points like addresses. These could be created and voted on by user adoption with the least popular x% being cut to keep the volume reasonable. For example, Paypal might be accepted. Paypal could actually exist as multiple options. Some might be willing to accept Paypal with a short escrow term of 1 week but with a low transaction limit like $20. Others might want no limit (or a high one) but require a 90 day escrow. Cash might be another option with one for each fiat currency and varied escrow terms. A little more thought might allow for a scheme that would allow this to take on an even greater role where these aren't just payment options but are in fact viewed as trade goods that might happen to sometimes be a Payment option like paypal. This view would mean someone could sell toasters via this system or a commodity like gold.

Buyers and Sellers is obvious. Every transaction would involve Bitcoin from at least one party and another party wanting to trade something for it. I'll refer to the non-bitcoin side as the buyer which is probably right for Paypal but wrong for toasters) and the bitcoin side as the seller. When a seller puts in an order his accepted currency options are attached to it and the coin associated is put in escrow for up to the escrow term on the relevant currency option. When matched with a buyer the buyer submits payment and the seller accepts on receipt or sets to automatically accept at the end of the escrow term.

Escrow. This is the tricky part. I'm thinking this might be handled with 2 of 3 multiple signing addresses. If everything goes correctly the buyer and seller sign and the escrow funds are released. The seller will always have submitted funds to escrow so if there is a problem it will be the seller claiming he didn't get paid or the escrow expiring. Either results in the network generating transactions to pay the escrow funds and the seller client and network both signing transactions to pay the escrow funds to unrelated third parties. These transactions should be signed at the earliest point possible and only submitted to the Bitcoin network if things go south. The idea here is that both parties share the risk. If the seller falsely claims he didn't his compensation he doesn't get his money back so at best he breaks even. If the buyer sends nothing or an empty envelope, etc, the buyer gets nothing in reward. The escrow funds could be utilized to reward the escrow processors who are sharing the burden of determining if escrow records are still needed, are expired, processing orders, etc. Order cancellation would be best effort with the result determined by network consensus. There may be options beyond that for the two parties if they come to agreement or via their payment option but that is outside the scope of the exchange.

A Shared Order and Escrow Ledger is needed to keep everything coordinated between clients. This will never be an ultra low latency trading platform with 1 min chart followers trying to follow the up and down ticks and using chart analysis. Thank god for that. But there will a potential advantage to positioning your connection to this network in a fast well connected location like a Datacenter with multiple peerings. This advantage isn't cheating in the way an ultra low latency trading platform is because everyone else would benefit from these well connected and fast nodes being placed in these positions, validating and propagating transactions to the shared ledger.

Most of the buyer/seller interaction could be automated in the client. Especially for a retail type situation where automatic conversion of bitcoin transactions into something like paypal transactions might be desirable along with automatic confirmation of payment receipt.



This all serves to give distinct advantages. A P2P instead of centralized exchange that is not subject to and needs no additional identity verification or regulation. The ability to make a personal choice regarding how anonymous you want to be versus how convenient you want currency conversion to be. It also gives you the ability to trade transaction speed for risk. Merchants have the ability to absorb a great deal of risk because they factor it into their costs and pass it back to consumers. Within reason they are willing to do this if you give them an easy road to follow. Merchants and consumers would benefit greatly by Bitcoin becoming the de facto transaction method.

Thoughts, questions, concerns? By all means, tell me why this is a shitbrained idea.


6  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: March 18, 2013, 06:20:48 PM
rBScs5VCwwzPgwYA63aH6WxCUxGQuvhJ7t
7  Alternate cryptocurrencies / Altcoin Discussion / Re: 1 Free LTC For You on: March 18, 2013, 06:19:26 PM
oooo me me me

LSb9i2Bs2teq27VyrY53qfnizHFFj37uGC
8  Other / Beginners & Help / Re: Newbie restrictions on: March 18, 2013, 02:17:27 PM
It does seem like this would encourage posting messages empty of content. What do others think?
9  Other / Beginners & Help / Re: Newbie restrictions on: March 18, 2013, 02:15:16 PM
This can be a little frustrating.
10  Bitcoin / Mining / Re: Simple? Question.. rpcminer on: May 23, 2011, 03:03:09 AM
Quote
The http:// address you want to connect to is the ip of the machine on the network. 127.0.0.1 is localhost and not accessible outside that computer.

Yeah. The mining client is running on the same machine. I didn't figure there was a point moving on to external clients if I can't connect to the daemon on the same box.

In any case, that config doesn't let me connect. Not on the lan address of the box or the 127.0.0.1 address.

Hopefully its a windows 7 related problem.



11  Bitcoin / Mining / Re: Simple? Question.. rpcminer on: May 22, 2011, 11:37:15 PM
rpc goes through http. That is why I was checking http. netstat -na confirms that the daemon is listening on 8332 (and 8333 for some reason). Windows firewall is off.

I don't really need a webpage. I need a mining client to be able to connect. Below is the rpcminer-cpu line I'm using and the bitcoin.conf. Replacing the url with the slush pool url and the username plus pass with my slush information works perfectly.

Code:
rpcminer-cpu -url=http://127.0.0.1:8332 -user=myuser -password=mypassword


Code:
 # bitcoin.conf configuration file. Lines beginning with # are comments.
 
 
 # Network-related settings:
 
 # Run on the test network instead of the real bitcoin network.
 #testnet=1
 
 # Connect via a socks4 proxy
 #proxy=127.0.0.1:9050
 
 ##############################################################
 ##            Quick Primer on addnode vs connect            ##
 ##  Let's say for instance you use addnode=4.2.2.4          ##
 ##  addnode will connect you to and tell you about the      ##
 ##    nodes connected to 4.2.2.4.  In addition it will tell ##
 ##    the other nodes connected to it that you exist so     ##
 ##    they can connect to you.                              ##
 ##  connect will not do the above when you 'connect' to it. ##
 ##    It will *only* connect you to 4.2.2.4 and no one else.##
 ##                                                          ##
 ##  So if you're behind a firewall, or have other problems  ##
 ##  finding nodes, add some using 'addnode'.                ##
 ##                                                          ##
 ##  If you want to stay private, use 'connect' to only      ##
 ##  connect to "trusted" nodes.                             ##
 ##                                                          ##
 ##  If you run multiple nodes on a LAN, there's no need for ##
 ##  all of them to open lots of connections.  Instead       ##
 ##  'connect' them all to one node that is port forwarded   ##
 ##  and has lots of connections.                            ##
 ##       Thanks goes to [Noodle] on Freenode.               ##
 ##############################################################
 
 # Use as many addnode= settings as you like to connect to specific peers
 #addnode=69.164.218.197
 #addnode=10.0.0.2:8333
 
 # ... or use as many connect= settings as you like to connect ONLY
 # to specific peers:
 #connect=69.164.218.197
 #connect=10.0.0.1:8333
 
 # Do not use Internet Relay Chat (irc.lfnet.org #bitcoin channel) to
 # find other peers.
 #noirc=1
 
 # Maximum number of inbound+outbound connections.
 #maxconnections=
 
 
 # JSON-RPC options (for controlling a running Bitcoin/bitcoind process)
 
 # server=1 tells Bitcoin to accept JSON-RPC commands.
 server=1
 
 # You must set rpcuser and rpcpassword to secure the JSON-RPC api
 rpcuser=myuser
 rpcpassword=mypassword
 
 # How many seconds bitcoin will wait for a complete RPC HTTP request.
 # after the HTTP connection is established.
 rpctimeout=30
 
 # By default, only RPC connections from localhost are allowed.  Specify
 # as many rpcallowip= settings as you like to allow connections from
 # other hosts (and you may use * as a wildcard character):
 rpcallowip=*.*.*.*
 #rpcallowip=192.168.1.*
 
 # Listen for RPC connections on this TCP port:
 rpcport=8332
 
 # You can use Bitcoin or bitcoind to send commands to Bitcoin/bitcoind
 # running on another host using this option:
rpcconnect=127.0.0.1
 
 # Use Secure Sockets Layer (also known as TLS or HTTPS) to communicate
 # with Bitcoin -server or bitcoind
 #rpcssl=1
 
 # OpenSSL settings used when rpcssl=1
 rpcsslciphers=TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!AH:!3DES:@STRENGTH
 rpcsslcertificatechainfile=server.cert
 rpcsslprivatekeyfile=server.pem
 
 
 # Miscellaneous options
 
 # Set gen=1 to attempt to generate bitcoins
 gen=0
 
 # Use SSE instructions to try to generate bitcoins faster.
 #4way=1
 
 # Pre-generate this many public/private key pairs, so wallet backups will be valid for
 # both prior transactions and several dozen future transactions.
 keypool=100
 
 # Pay an optional transaction fee every time you send bitcoins.  Transactions with fees
 # are more likely than free transactions to be included in generated blocks, so may
 # be validated sooner.
 paytxfee=0.00
 
 # Allow direct connections for the 'pay via IP address' feature.
 #allowreceivebyip=1
 
 
 # User interface options
 
 # Start Bitcoin minimized
 #min=1
 
 # Minimize to the system tray
 minimizetotray=1
12  Bitcoin / Mining / Simple? Question.. rpcminer on: May 22, 2011, 11:02:10 PM
I've tried this on a couple windows 7 machines now. bitcoin -server with a bitcoin conf specifying username/password/port/allowed ip simply doesn't work.

I can connect to http://127.0.0.1:8332 and it prompts for a username and password but returns a page not found... this should be dumping something in json format yes?

rpcminer pointed to that address with correct user and password parameters just says it can't retrieve work.

Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!