Bitcoin Forum
April 03, 2020, 10:02:36 AM *
News: Latest Bitcoin Core release: 0.19.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Marketplace (Altcoins) / Re: Buying Ripple on: June 13, 2014, 02:15:30 PM
Acquire BTC, move it to Bitstamp, convert half or more to USD, then withdraw the USD and BTC to your Ripple wallet. You can easily acquire that much XRP over a few days within the Ripple system itself using the USD and BTC. There is a fair bit of liquidity right now.
2  Bitcoin / Project Development / Re: [ANNOUNCE] Zero Reserve - A distributed Bitcoin Exchange on: December 19, 2013, 12:49:31 PM
Hey anu, cool project, congratulations!  It's great to see other implementations of the Ripple concept, and that you are here explaining it to people.

Maybe this will help explain why Ripple is an improvement over exiting debt-based monetary systems:

http://archive.ripple-project.org/paymentrouting.pdf

Quote
The payment systems we have today are designed as hierarchical trust networks for easy payment routing and rely heavily on active regulation to protect the delicate points of failure inherent in this type of structure. Regulation has been at best only moderately successful -- destabilizing "attacks" on national currencies by speculators are a regular occurrence -- and always controversial, as various interest groups compete to use single points of control as levers for advancing their agendas.

There are alternatives to the present arrangement. The Internet demonstrates the feasibility of routing information in an arbitrary network, by developing a standard protocol. Payments are nothing but information about obligations -- if paths can be found to route information, paths can be found to route payments. The difference is that while information is routed along "best-effort" paths through physical data networks, payments must be routed along reserved paths through abstract trust networks. Billions of trust relationships that exist outside the tightly-regulated global hierarchical currency network could be integrated into that network, removing single points of failure without harming the value of existing obligations. The resulting network would be more stable, and therefore require less regulation and be less expensive to use, while at the same time being more democratic and responsive to local concerns.

I think Ripple (in whatever implementation) and Bitcoin complement each other and will grow better together than separately.
3  Economy / Speculation / Re: Ripple competition on: November 22, 2013, 05:33:57 AM
So there's Nxt, MasterCoin, BitShares (or is it ProtoShares?), eMunie, Open Transactions, all of which are supposedly going to be launched/released soon (any others?). It is very easy to market vaporware - just claim that your product has feature X, and it does. Since its just vaporware it can have all the best features before it even exists.

Ripple, on the other hand, actually exists and already has one major gateway (kraken next in line) and two chinese gateways (with rising CNY capitalization btw, up from 250k CNY in october to 539k CNY on Nov 12th to 787k CNY today).

The competition hasn't even left the starting line.

If anyone wants to implement my original 2-phase-commit/non-blockchain Ripple protocol design, it's here:

http://archive.ripple-project.org/Protocol/Protocol

It's only based on IOUs and routing through a mutual credit network -- no trustless cryptocurrency involved.  And you'd need to give it a different name, of course Smiley
4  Bitcoin / Electrum / Re: Bug: Download page not secure on: June 06, 2013, 12:45:30 AM
Use PGP.

I see the signatures, but where do I find the public key to verify against?
5  Bitcoin / Electrum / Bug: Download page not secure on: June 02, 2013, 04:56:24 PM
It would be far preferable if the page at

http://electrum.org/download.html

was secured by https so I could trust that the information given there, particularly MD5 checksums, has not been tampered with on its way to my browser.  Thanks!
6  Alternate cryptocurrencies / Altcoin Discussion / Re: Tiniest Ripple "Satoshis" should be called "Fuggers" to honor Ryan Fugger on: May 31, 2013, 03:31:28 AM
Haha, good one Smiley

How's the Ripple-style multi-hop transaction routing functionality coming along in Open-Transactions?  Let me know if I can help at all.  Ripple is great, but I think it would be nice to also have a multi-hop system where transactions aren't published to the whole world.  I'm sure they can be made to interoperate at some point down the line too...
7  Alternate cryptocurrencies / Altcoin Discussion / Re: XRP distribution proposal: the paying faucet on: April 03, 2013, 04:47:27 PM
Let me ask you a question: why would you accept someone's IOUs instead of XRPs?

You'd accept IOUs for three reasons:

1. The payer may not have XRP, since those are in finite supply and take effort to acquire.

2. XRP, like BTC, isn't be a great unit of account, since its value hasn't stabilized yet.  Unless you want to constantly be keeping an eye on the current XRP price and doing conversions back to more stable units, like dollars, or better yet, something like Terras, in your head.

3. You are unhappy that a small group controls the majority of XRP and you'd rather not use it for payments.
8  Alternate cryptocurrencies / Altcoin Discussion / Re: Ripple Giveaway! on: March 05, 2013, 10:30:49 PM
r4cA3L7ibT4p6kmEsYqE3YVc6MzjgaPH66
9  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: August 19, 2011, 06:57:55 AM
I managed to write down what I conceptually want to create. You can read the description here.

Notice the difference with the Ripple, in the use of a shared Bitcoin wallet to back IOUs.

I don't know whether this can be implemented on the Ripple network. I suspect it is not possible: if I am correct, there are only a limited number of message types in the Ripple protocol, and some of the things I want to do probably don't fit in these message types.

You could certainly build this on top of Ripple as a particular kind of trust account (shared bitcoin wallet).  Nothing about the payment routing would be affected as far as i can see.

Ryan
10  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 05:11:48 PM
There must be some kind of timeout.  If I promise to pay X, then I need to reserve that portion of the trust link.  If the IOU isn't cashed in, then I can purse the funding lock.

Yes.  It should be possible to have a timeout on the order of seconds, though, since that's how long a successful transaction should take.
11  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 05:07:06 PM
Hm.

How about this:

I'm A, I want to pay one btc to B with fast validation.   I have a preexisting relationship with C, and B has a pre-existing relationship with B.

I give C a signed transaction with an nlocktime somewhat in the future, covering the the amount, any fees C is charging me, and any BTC txn fees.  C gives a similar open transaction to B.    

If there are more exchanges between any of the parties we replace the transactions with updated versions that reflect the new outstanding balances. All of the is hidden from the blockchain until the locktime runs out.  After some time has passed without any changes, the lock time arises and the latest version of the transactions are published, settling the accounts.

A<->C can settle independently of B<->C.

Parties are vulnerable to double spending of the committed funds, but thats why they have a pre-existing trust relationship. They are assured that their activities are backed by funds their trusted peer hasó at least fractionally (in the case of double spending).

This obviously works when C is a chain of parties too.

That's pretty cool, but I'm not sure I see the benefit of the open transactions if you need to fully trust the other party anyway.  Why can't they just send normal transactions when it's time to settle?
12  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 04:43:29 PM
So my big question is: what percent of all transactions go to 0/unconfirmed and never actually verify? Is there any way to find this number and compare it to the percent of all credit card transactions which are reversed, transaction fees and CC fraud?

Most merchants are pretty accustomed to a plethora of possible fees and reversal scenarios for CC payments and as such have typically rolled an amount of expected loss into their business plans. The point of bitcoin is to make reversals impossible and blockchain errors rare - no matter what we do there will still always be a margin of error and a small bit of fraud. What's important isn't creating a flawless system, what's important is creating a BETTER system. If we can (provably) show that the expected rate of loss for BTC is drastically lower than credit card transactions and make it easy to use, merchants will adopt it more readily.

The problem is that if merchants are told to just trust transactions that haven't been confirmed, then there is the possibility that the losses will be quite high.  The face that only a small percentage (zero?) of transactions are currently double spending isn't relevant, because no one out there is trusting transactions until they've been confirmed, so double-spending isn't a viable exploit.
13  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 04:07:27 PM
I think that is similar to the suggestion to use the bitcoin chain itself as register.

Sure, except it happens in real-time.

You should add a packet length field to your message system.

Each frame header has a length field.

Quote
This allows older clients to ignore (or forward) any new packet types.  It also allows clients to use non-standard packets.

For this I have frame version and type fields in the frame header, and message type in the message header...  I don't think I need message length, because the frames should be reliably reassembled into messages, and the messages should be signed if their content is important.  Am I still missing something? 

Thanks,
Ryan
14  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 02:52:37 PM
Yeah, I was wondering how you were planning to handle that.  A node could end up holding an IOU to the last link and then suddenly the transaction is canceled and he has an IOU from someone he doesn't trust.

The mechanism is that each node first promises the one ahead that it will pass an IOU in exchange for a commit token signed by a certain key, determined by the last node (the payment recipient).  Once all the promises are made, the recipient generates a commit token and passes it back to the previous node in exchange for an IOU, and so on back to the first node (the payer).

This is enough if all the nodes remain online and they are all well-behaved, but in case not, I've proposed a system of commit registries as an extension that should be fairly robust against node failure and cheating:

https://groups.google.com/forum/#!msg/rippleusers/Ruy_QIb0AAY/fUF5bGNJWXkJ

Ryan
15  Bitcoin / Development & Technical Discussion / Re: A proposal for fast POS transactions with Bitcoin on: July 14, 2011, 01:51:30 PM
Hi.  I'm the founder of the Ripple project.  Nice to see Ripple being discussed as a real-time transaction overlay for Bitcoin.  I think the two are complementary -- Bitcoin is decentralized virtual gold, and Ripple is decentralized virtual banking. 

I'm working on a generic Ripple server to support the next version of Ripplepay.com that I intend to release as open source.  It won't be distributed at first, but it would work as a central server to query for routes (and also to process transactions atomically, which is probably actually a harder problem than routing in a distributed setup).  My design for a distributed Ripple protocol is here:

http://ripple-project.org/Protocol/Protocol05

Comments and suggestions are welcome.  If anyone is interested in helping with this, or just interested in implementing some kind of Bitcoin banking on top of it, let me know.

Thanks,
Ryan
16  Bitcoin / Development & Technical Discussion / Re: A block chain for real-time confirmations on: March 12, 2011, 01:13:57 AM
If I get you... In your proposed system generating normal blocks would not be computationally intensive, but generating transactions would be.
Isn't this going the wrong way? This places the weight of the system on merchants with the rest of the market participants simply acting as consumers.

Perhaps, but merchants will always pass along the cost of the system to their customers...

Quote
And what's to keep a couple of nodes from making dummy purchases from each other simply to create coin? That sounds more like banking as it exists today IMO.

You can't generate coins by making a dummy purchase.  You have to hold a coin to make normal transaction.  You would only be able to generate coins by creating a coin-generating block, which would require the same target difficulty as the current system.
17  Bitcoin / Development & Technical Discussion / Re: A block chain for real-time confirmations on: March 12, 2011, 12:46:15 AM
0.01 of a confirmation on your network is actually worse than 0 confirmations on the Bitcoin network. With 0 confirmations you are protected somewhat by the TCP-level network, but anyone can reverse a transaction with 0.01 confirmation, overruling the TCP-level network.

Yes, as a payment recipient you would still have to wait until the cost of creating a conflicting parallel stream with a greater proof of work than your stream was greater than the value of the payment.  But for small payments, that might not be very long at all.  Right now, a 10-minute block is worth somewhere in the neighbourhood of $45.

It's a lot more data that lightweight clients will have to download. There's an 80-byte header per block that clients need. If this was required for every transaction, then lightweight clients would have to download about 17MB more data currently. This will become a lot more significant as the number of transactions per block increases. Also, if you have multiple "previous block" hashes in each transaction, you'll need headers that are much larger than 80 bytes. Normal clients will quickly lose the ability to send transactions.

Ah, I was only considering full clients.  Fair point.  With my proposal, if you didn't have enough bandwidth to receive all the transactions, you wouldn't be able to verify the proof of work in the chain.

There is no independent rate of block creation or target difficulty anymore.  Just one block per transaction, whenever a transaction happens, with whatever proof of work the submitter can generate.  So "blocks" will get generated continually.  ("Block" isn't a suitable word anymore, because it implies a grouping of transactions, which isn't the case here -- it makes more sense to just say "transaction" .)

OK then, how do you control the rate of currency inflation? Seems as though you are talking about a fundamentally different system that uses some of the same tools.

Normal "blocks" wouldn't generate coins anymore, since there is no target difficulty.  You could still have coin-generating blocks, but they would only contain the generating transaction, and have to meet a target difficulty.  Two generating transactions in parallel streams would conflict.  See my post re: generating transactions. 

It is a somewhat different system in that it shifts the burden of proof of work from a few block-computing machines, to anyone who wishes to record a transaction. 
18  Bitcoin / Development & Technical Discussion / Re: A block chain for real-time confirmations on: March 11, 2011, 09:10:16 PM
Further thoughts:

Anyone would be able to add proofs of work onto this kind of chain, continually making it stronger, by submitting zero-value transactions.  Peers who recently submitted transactions would be motivated to do this to ensure their transactions get sufficiently buried.  They could even pay others to do this for them if they wanted, which would be just like transaction fees in the current system.

You could still have coin-generating transaction blocks with a set target difficulty -- they would just include the one coin-generating transaction, though, but would need to have a reasonably current set of predecessors to be accepted.
19  Bitcoin / Development & Technical Discussion / Re: A block chain for real-time confirmations on: March 11, 2011, 09:02:28 PM
That doesn't help much. You need to wait until your transaction is buried deep enough in the chain for an attacker with less than 50% of the network's computational power to be unable to reverse it. If there are many smaller, easier blocks, you'll just have to wait 300 confirmations (or whatever) until that target is reached. In other words, you always must wait for the network to do a lot of work after your transaction.

It would provide more fineness in desired confirmations; you could accept transactions with 2.5 Bitcoin-equivalent confirmations. But it's bad for scalability, and the increased fineness isn't valuable, IMO.

Good point.

I would argue that it would be valuable to have finer-grained confirmations for the sake of speed.  In a point-of-sale situation, for example, being able to confirm a small transaction quickly is very important.

Can you elaborate on how it hurts scalability?  Isn't it all the same data being passed around?

Thanks.
20  Bitcoin / Development & Technical Discussion / Re: A block chain for real-time confirmations on: March 11, 2011, 08:55:55 PM
If you want a real time confirmation, patch the client to check if the sender really have coins (it may already do this). Once it's done, you don't need to really wait for inclusion in 6 blocks, or even in 1 block (but a transaction can currently be ignored by all blocks and forgotten, or depends on another transaction still not included, so 1 block may be a minimum of security)

Right, you should wait for at least one block to have pretty good reassurance.  That's a few minutes on average, not enough for point-of-sale, for example.

Wouldn't this be the same as having only one transaction per block?

Yes, with the addition of the capability of merging parallel streams.

How that merge would be made?

Instead of including the hash of a single predecessor block, you would include the hashes of all predecessor blocks.  For the proof of work, you would hash the root of a Merkle tree of all the predecessors, just like you do to include multiple transactions in blocks now. 

But if that were true then transaction volume would be pegged to the rate of block creation. The only way to increase circulation would be to have bigger transactions... Won't work.

There is no independent rate of block creation or target difficulty anymore.  Just one block per transaction, whenever a transaction happens, with whatever proof of work the submitter can generate.  So "blocks" will get generated continually.  ("Block" isn't a suitable word anymore, because it implies a grouping of transactions, which isn't the case here -- it makes more sense to just say "transaction" .)
Pages: [1] 2 »
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!