Bitcoin Forum
May 09, 2016, 01:09:16 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 [88] 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 »
1741  Economy / Marketplace / Re: Trusting sellers of LARGE amounts of Bitcoins on: February 04, 2011, 07:53:46 PM
@Gavin, why would the seller in your scenario be anymore protected against paypal frauds than all others selling hard currency for paypal? Just the presence of a delivery address you think is enough?

Yes, the delivery address and the fact that you're selling a physical product (the USB stick).

Kind of like how you used to be able to buy cheap OEM copies of software but they had to ship a token piece of hardware in the box so they could say they were hardware vendors...  (actually, can you still do that any more?)

1742  Economy / Marketplace / Re: Trusting sellers of LARGE amounts of Bitcoins on: February 04, 2011, 07:02:44 PM
Good Idea.  I think the PDF signing is overkill, but Good Idea.

Here's a bitcoin business I want somebody to create and run:  "Coin on a Stick"

You sell USB sticks containing Mac and Windows versions of the latest bitcoin (including the entire block chain) plus a wallet file containing N bitcoins.

Sell them via Ebay or PayPal, and ship them ONLY to a PayPal-verified address.

The buyer has to trust you not to double-spend the coins in the wallet, and has to wait for delivery of the physical USB stick.  But they don't have to download or install anything (they should be able to just run bitcoin from the stick and transfer the coins to themselves or a mybitcoin or mtgox account).

But, since you are sending a physical product to a verified address, you'll be treated as any other merchant selling real goods by PayPal or the credit card companies.
1743  Bitcoin / Development & Technical Discussion / Re: Suggestion: Introduce penalty for attempted double spend on: February 04, 2011, 06:41:23 PM
So as a merchant, you would then receive a transaction, broadcast it and wait - let's say 5 seconds - whether you see any conflicting transactions. If not, you accept it. If the attacker still manages to pull of a well-timed double spend, you know at least, that when the next few confirmation blocks come around, the fraud will be punished.

So if the merchant sees an attempted double-spend within 5 seconds they accept the bitcoins but don't give the merchandise/service/whatever.

That sounds like a good idea to me.  Maybe instead of 5 seconds it aught to be "before the transaction is fully confirmed."

The only drawback I see is buggy clients that might have bugs that cause 'honest' double-spending mistakes.

Oh, and merchants would have to explain to customers whey they kept their double-spent coins (although the merchants could easily produce both transaction IDs to show the world that it WAS a double-spend, so they shouldn't have to worry about their reputation being sullied).
1744  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 04, 2011, 06:33:36 PM
But going back to my original question: is there a unique way to identify a block even in the face of reorgs?

Sure, every block has a unique hash.

But I don't think that helps at all; you might see that transactions A B C D are in block #100,000 with hash H1, but after a block chain re-org block #100,000 might contain transactions A D (with block hash H2).

The probability of that happening rapidly approaches zero as the block gets confirmed; after 6 confirmations you can safely assume it just won't happen.

1745  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 04, 2011, 04:34:15 PM
Anyway, as I mentioned I'm not that familiar with the inner workings of the Bitcoin protocol, so I'm making lots of assumptions.  I hope you can fill the blanks, because without an API that allows clients to have a fool-proof way of ensuring transaction consistency it will be very hard for Bitcoin to be taken seriously for e-commerce applications.

The fool-proof way of dealing with your use case (customer orders something, you want to ship after you're sure payment has cleared):

+ Give each customer an account.  When they order, use getaccountaddress to get a bitcoin address to which they can send payment.

+ Every N minutes ask bitcoin either the balance (with minimum 6 confirmations) for accounts with pending orders or all accounts

+ If the account balance is enough to pay for the order, ship it and move the coins from the customer's account to a PAID account.
   If not... either wait or tell the customer they paid the wrong amount or maybe refund any extra they sent (you'll have to ask them for a refund address).

The inelegant polling will eventually be fixed by bitcoin POSTing when new blocks or transactions arrive, but I think you'll still need to ask bitcoin what the account's current balance is-- trust me, you really don't want to recreate all the bitcoin logic dealing with double-spent transactions or block chain reorganizations.

If you grow to handling thousands of orders per day (which would be a very good problem to have) you'll want to buy or build a version of bitcoin optimized for high-volume transaction websites.  Or maybe you'll run 20 bitcoinds, each handling 1/20'th of the customers -- I dunno, I don't spend a lot of time worrying about problems I'll have when my project is outrageously successful.
1746  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 03, 2011, 09:13:55 PM
Okay, let us consider that scenario.  Step by step, just to make sure we are on the same page:
  • The Bitcoind daemon knows of transactions [A, B, C, D] with timestamps [T1, T1, T2, T2].
  • Upon first invocation, the client asks for a list of all transactions.  It receives [A, B, C, D] (and timestamps) as response.
  • There's a block chain re-org invalidating [C, D].

No, there is a block chain re-org invalidating B and C.  D is still valid in my scenario.

So the client remains oblivious to B and C being invalid, whether it asks for transactions older than T2 or transactions after D.
1747  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 03, 2011, 07:01:27 PM
I thought of that as well, but how would the client know if a previously obtained list of transactions had been invalidated?

Huh?  I don't see how passing <txid> makes that problem any better.

Let's say you've got transactions A B C D (in that order).  With times T1, T1, T2 and T2 (A&B happened 2 blocks back, you got C&D in the last block).

Now imagine a block-chain re-org, so B and C are now invalid.

Ask for all transactions after D and you get nothing-- same as if you asked for all transactions with time greater than T2.
1748  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 03, 2011, 06:03:12 PM
If an optional time param is needed, maybe get rid of the "since <txid>" notion and just make it "give me all receive transactions for [account] with [minconfirmations] that have a time greater than [time]".

1749  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 02, 2011, 05:35:48 PM
Nice, I like your proposal.

Do you know C++?
1750  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 02, 2011, 05:07:40 PM
Yes, there are "behind the scenes" actions that must take place regardless of user intervention.  Suppose the user has bought something; I want to be able to ship the item as soon as the bitcoin transaction is confirmed.

Transactions are confirmed when new blocks are accepted; that's the idea behind my 95%-finished 'monitorreceived' code.  It will POST to a URL when new wallet transactions and blocks are accepted.  The block information includes all transaction ids (and a link to the previous block).

As you note, you still have the issue of what to do if your code misses a POST.  That shouldn't be a big issue, though, because you'll resynchronize the next time a block is found.  Worst case, you'll ship to the customer 1 block (10 minutes) later than is optimal if your connection to bitcoind is lost.
1751  Bitcoin / Bitcoin Discussion / Re: Building our decentralized web identity on: February 02, 2011, 04:55:18 PM
Good idea.

I think the first spot for plugins in bitcoin should be "send address resolver" services-- If I tell bitcoin "send 100 bitcoins to obama@whitehouse.gov" it could ask the plug-in resolvers (in some user-defined order) "do you have a bitcoin address for obama@whitehouse.gov" ?

If I tell bitcoin "send 100 bitcoins to eff.org" maybe a different resolver is used (DNSSec query to eff.org to get a bitcoin donation address, perhaps).  Or "send 11 bitcoins to +01-1-805-253-2751" ...

There are lots of potential problems, of course, ranging from what if the resolver software service/author starts redirecting bitcoins to them to what if the user misspells the destination.  That's why I think starting with a way of pluggin-in different solutions to try is the right way to start.
1752  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 02, 2011, 04:10:24 PM
How do you think the code should deal with the issue of "a fixed txid might no longer be valid" ?  Or transactions that you THOUGHT had N confirmations and were in a block with timestamp T are re-organized to have M confirmations and are in a block with timestamp T2 ?

tcatm and I chatted in IRC about this problem-- he has the problem of how to keep the Javascript GUI (which shows you ever transaction) up-to-date.

Seems like you really want an efficient way of asking "Do I know about exactly the same set of transactions as bitcoind" (either for the entire wallet or for an account).  That's assuming transaction data can't change (somebody double-check that assumption for me-- if the transaction data changes, then the txid changes... I think).

That led to some brainstorming of computing a hash of all transaction ids (maybe just XOR them all together).  Or maybe something more complicated like a merkle tree...   but that seems like overkill.

Is there a good, simple solution to synchronizing "I have this set of stuff, give me everything I don't have" ?
1753  Bitcoin / Development & Technical Discussion / Re: [RFC] Testnet reset on: February 02, 2011, 02:56:54 PM
Keep testnet as close as possible to the live system. It will sort itself out in a few weeks.

Create an additional block chain for those whose development needs require something other than what testnet provides.

No, it won't sort itself out "after a few weeks".  Let me see if I can do a back-of-the-envelope:

Difficulty on testnet currently at 373.  We want it no higher than, oh, 5, so with the typical 3-or-4 machines CPU-hashing on testnet generate a block in a reasonable amount of time.

So we generate 2016 blocks over 8 weeks.  That cuts difficulty by four: ~90
Then do it again: ~22
and again... ~5  SIX MONTHS later

That's optimistically assuming we can find people to cooperate to contribute hashing power to generate 2016 blocks at difficulty 300 in 8 weeks or less.

If you'd like to continue using the old testnet chain, be my guest.

I'm sympathetic to the "testnet and main net should have the same rules", but the truth is the testnet has, and always will have, many fewer people hashing on it.

Changing the main net downard-difficulty-adjustment code might make sense, but that's the topic for another thread.  Allowing main net difficulty to adjust all the way from 22,000 to 1 isn't the right answer (it makes sybil attacks where an attacker feeds you a bogus version of the block chain much easier).
1754  Bitcoin / Technical Support / Re: Can I safely run multiple identical bitcoind instances ? on: February 02, 2011, 04:21:56 AM
Giving them all the same starting wallet is a bad idea; they will start out with the same keys, but will eventually each generate their own, so their balances will drift out of sync.

In theory everything should work out, but in practice using the same wallet on multiple machines hasn't been tested much (I fixed a couple of bugs in the last couple of weeks related to a wallet shared between machines).

So before cloning, delete the wallet.dat (assuming it has no bitcoins in it) and let the clones automatically generate a new wallet the first time they start.
1755  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 01, 2011, 08:50:05 PM
Here's my use case: suppose I have a potentially large number of users making transfers directed towards me (each using a separate account).  My application will need to periodically poll the bitcoin daemon to find out what new transfers have been confirmed, so it can update the user's account/assets on the application side.

Two thoughts:

listaccounts [minconfirmations]  (also new in 0.3.20, if I'm remembering correctly) will give you all accounts and their balances.  If an account's balance doesn't change, you know it hasn't received coins.

And why do you need to periodically update the user's account/assets?  Could you just query bitcoind for their current balance when they fetch their 'account status' page (or wherever you show the user how many bitcoins they have)?  Are you doing something with the received bitcoins without an explicit action on the part of the user, and does that something care about the total balance or individual transactions?
1756  Bitcoin / Development & Technical Discussion / Re: Obtaining all transactions since a given txid on: February 01, 2011, 06:00:39 PM
0.3.20 will support listtransactions '*'  for all transactions.

Transactions since <txid> ....  sounds dangerous.  Are you trying to mirror the transaction database that bitcoin keeps?  If you are, are you sure you'll deal properly with (rare) block chain re-organizations where transactions that you thought had one confirmation turn out to be invalid in a new fork of the chain?

I can imagine subtle bugs-- you ask for transactions since <txid> but that txid turns out to be an orphan transaction (double-spend on the losing side of a block chain re-org) so bitcoin returns... what?

All non-orphan transactions with transaction time equal to or greater than a given timestamp might work-- but what is your use case?
1757  Bitcoin / Bitcoin Discussion / Re: F2F bitcoin network on: February 01, 2011, 05:51:08 PM
You can setup your own f2f bitcoin network using the -connect option, connecting only to friends.

One of those friends must be connected to the rest of the bitcoin world, of course.

Experimenting with sending transactions and blocks over XMPP or some other network is a great idea-- go for it!  It shouldn't be hard to create a "bitcoin bridge" that relays traffic on the main bitcoin network to/from another network.

1758  Bitcoin / Development & Technical Discussion / Re: Interface Optimization on: February 01, 2011, 01:38:22 PM
So... who's excited about doing either a little wxWidgets programming or a lot of "port the bitcoin GUI to Qt" programming?

This isn't going to happen unless somebody actually does it...
1759  Bitcoin / Development & Technical Discussion / Re: [RFC] Sub-cent-precision on: January 31, 2011, 03:38:22 PM
I split this into it's own thread.

Here's a counter-proposal:

All RPC methods dealing with amounts take and report full-precision bitcoins.
E.g. if you have 1 BTC getbalance reports 1.00000000  (as it does now)
The send and move methods will be changed to NOT round to two decimal places.

luke-jr's patch that makes bitcoin avoid creating sub-cent change (when possible) will be applied.

The GUI will be modified to display full precision amounts, and will allow full-precision sends.
  (if you have 1 BTC, GUI should show balance: 1.00
   if you have 1.0001 BTC, GUI should show balance: 1.0001
   ...etc)

A new setting: maxtxfee  will be added, default will be 0.01 BTC.  RPC methods will fail with a new error message if a send/sendfrom would generate a transaction fee larger than maxtxfee.

A new RPC method to change maxtxfee setting (maybe a generic RPC method to change any run-time option that can be changed on the fly?)

The code should be checked and all references to CENT which really mean "minimum transaction fee" should be changed to reference a new "minimum transaction fee" constant (==CENT for now).
1760  Bitcoin / Development & Technical Discussion / Re: [RFC] Testnet reset on: January 31, 2011, 02:32:00 PM
Patch/pull request is:
  https://github.com/bitcoin/bitcoin/pull/53

Pages: « 1 ... 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 [88] 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 »
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!