Bitcoin Forum
May 09, 2016, 01:02:57 AM *
News: New! Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  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 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 ... 114 »
701  Bitcoin / Bitcoin Discussion / Re: Skeleton key? (was: Bitcoin press hits, notable sources) on: April 12, 2012, 05:30:55 PM
Split from the press hits topic:

The only "skeleton key" I have is the private key for alert messages, that lets me sign messages that are broadcast and then displayed in the client (see https://en.bitcoin.it/wiki/Alerts for details, and the alerts that have been sent).

MAYBE he is saying that the core developers could slip in a change to the source code without anybody else noticing... but we've worked hard to make that impossible (with things like the gitian reproducible build system so people can verify that we are creating executables from the source code that anybody can look at).

Smells like plain-old FUD to me.
702  Bitcoin / Development & Technical Discussion / Re: TX replacement and nLockTime on: April 12, 2012, 04:22:55 PM
A Bitcoin in which miners can and do vote on how much inflation they'd like to award themselves is not a Bitcoin I'd feel like participating in. But it's the logical outcome of assuming miners are a perfectly informed conspiracy of entirely selfish actors.
The Bitcoin ecosystem consists of more that just miners, and even if miners decided to try to form a cabal to increase inflation merchants, users, and exchanges could all veto their block-chain by simply refusing to recognize it.

I think the policy of which transactions to keep in the memory pool is fundamentally different, because miners can do whatever they like and there's not a whole lot merchants/users/exchanges or other miners can do about it. There's no way to enforce a "first broadcast version of a transaction must be mined" rule, if there was then we wouldn't need the block chain at all.

As for re-writing the blockchain if an after-the-fact, large-fee double-spend is broadcast:  I think that's covered by this case:
Quote
Should a miner put Transaction 1 into the block they're mining and take the smaller fee now, or not include it, hoping that nobody else mines Transaction 1 in the next 3 days so maybe they can mine Transaction 2 and get the bigger fee?

I'm not an expert in game theory, but I believe the winning strategy in the above situation, assuming everybody knows about both transactions, is to mine Transaction 1 right away (any economists reading who know a lot more about game theory than I do?).
Or, in other words, you'd need to be pretty sure that you've got a majority of miners who will cooperate with you to rewrite the block chain. The longer the chain, the harder that will be (because it becomes increasingly likely that one of your co-conspirators mined one of the blocks you want to overwrite).
703  Bitcoin / Development & Technical Discussion / Re: TX replacement and nLockTime on: April 11, 2012, 06:21:11 PM
Please let's just try and use the tools Satoshi left us with rather than constantly trying to change them. I'm strongly against trying to "improve" parts of the protocol that we've barely even begun to understand yet, like nLockTime and tx replacement.
Some of the big mining pool operators are already going their own way, experimenting with new types of transactions (e.g. deepbit and eligius), so I suspect the answer to your question "Can 'we' please hold off..." is "No."

Discussions like this one are how I start to understand parts of the protocol like nLockTime and transaction replacement better.


As for BIP 16 draining effort away from making the standard client scale:  I've been saying for a year that my top priorities are network stability and wallet security. Making the standard client scale is, in my opinion, a lower priority; I don't want a super-scalable client with a 4-minute blockchain initial block sync time if it is vulnerable to the user clicking one wrong link and getting infected by a trojan wallet stealer.
704  Bitcoin / Bitcoin Discussion / Re: [ANN] Cryptocurrency Legal Advocacy Group (CLAG) on: April 11, 2012, 01:46:23 AM
As I told Matthew when I spoke with him a couple of weeks ago, I also think this is a fantastic idea and plan on helping the CLAG however I can. Legal and regulatory uncertainty is perhaps the biggest barrier for companies who might be thinking of launching projects involving Bitcoin, and having a reliable source of up-to-date accurate information about the issues will be incredibly valuable.

Hopefully in a couple of years the CLAG's biggest problem will be figuring out what it's role should be as similar groups, inspired by the CLAG, spring up all over the world to tackle the unique legal issues in each country.
705  Bitcoin / Development & Technical Discussion / Re: TX replacement and nLockTime on: April 10, 2012, 06:37:37 PM
The issue, of course, is that it's not really feasible to have regular users contacting miners to help them replace tx like this (in the event that the seller broadcasts the 31-day tx right away, hoping the buyer can't figure out how to replace it).  Also, I didn't like the idea that anyone would be able to bribe a miner to replace their 0-confirmation tx.  But that's a whole 'nother story...
In the long run, I think we have to assume that miners will do what is most profitable, and design escrow/payment protocols around that assumption.

Replacing non-final transactions in the memory pool potentially opens up a whole bucket of worms, but I think the short-term challenge is to figure out if we should change the rules we have now. If we do (I think we should), then I think it would be a mistake to do anything other than "create rules that will maximize miner profits."  Because if we do something else, then sooner or later I believe there will be a "miners special" version of the code that has miner-friendly rules.


If you agree with me that the default rules in the client should maximize miners' profits, then it seems to me there's one simple rule change we should make:

If you've got two otherwise equivalent transactions that spend the same input(s), keep the one with the most fees.

Right now, the rule is "keep the first one you see."

The bag of worms comes into play if you've got two transactions that spend the same input(s) that, for example, look like this:

Transaction 1:  final transaction (can go into a block RIGHT NOW) that has a fee of 0.005 BTC
Transaction 2:  transaction that won't be final for 3 days that has a fee of 0.1 BTC

Should a miner put Transaction 1 into the block they're mining and take the smaller fee now, or not include it, hoping that nobody else mines Transaction 1 in the next 3 days so maybe they can mine Transaction 2 and get the bigger fee?

I'm not an expert in game theory, but I believe the winning strategy in the above situation, assuming everybody knows about both transactions, is to mine Transaction 1 right away (any economists reading who know a lot more about game theory than I do?).

That suggests the rules for transactions that spend the same inputs aught to be:

1. If you have two free transactions, keep the first one you see.
2. If you have a free and a fee-paying transaction, always keep the fee-paying one.
3. If you have two final, fee-paying transactions, keep/mine/relay the one with the higher fee.
4. If one or both of the transactions is non-final, keep/relay the one that will become final first.
706  Bitcoin / Bitcoin Discussion / Re: Version 0.6.0 released on: April 08, 2012, 07:24:59 PM
When I use the bt command, I get this:
....
Thanks, that should be very helpful.  I opened issue #1065 https://github.com/bitcoin/bitcoin/issues/1065
707  Bitcoin / Development & Technical Discussion / Re: A proposed solution to adjust for lost Bitcoins: wallet 'heartbeats' on: April 08, 2012, 07:06:23 PM
Extending Bitcoin to new and wonderful types of transactions is fine, and, actually, I believe Therilith could build most of what he wants on top of Bitcoin
I don't think you are interested in wonderful types of transactions, may be even the opposite.
Now the rules are more strict and inputs are being checked for being standard too Sad

We had the chance to enable more opcodes inside P2SH, but it didn't happened...
Write up a proposal, start experimenting on testnet, recruit people to think really hard about how whether or not what you're proposing could be abused to compromise security or could make a denial-of-service attack easier...

I'm against changes that might make Bitcoin a tiny bit better, but if you've got a well-thought-out proposal for how to make Bitcoin much better in some way then I'll help you argue for it.
708  Bitcoin / Development & Technical Discussion / Re: A proposed solution to adjust for lost Bitcoins: wallet 'heartbeats' on: April 08, 2012, 03:13:58 PM
Don't worry, they don't have any chance to win Smiley
+1

Personally, I consider the coin creation function (50 BTC every 10 minutes, halving every 4 years) and rules for whether or not you can spend the coins you have (if, and only if, you can satisfy the scriptPubKey by creating an ECDSA signature then you can spend them) sacrosanct. Them's the rules of Bitcoin, change them and it ain't Bitcoin any more.

Extending Bitcoin to new and wonderful types of transactions is fine, and, actually, I believe Therilith could build most of what he wants on top of Bitcoin using pre-signed fee-only non-final transactions with a lockTime 10 years in the future.

Convincing people to agree to do that would be another thing all together...
709  Bitcoin / Development & Technical Discussion / Re: Buyer-Seller Escrow Transactions (with or without 3rd-party) on: April 08, 2012, 03:03:43 PM
I just realized one complication -- the 2-of-2 tx (or 2-of-3) has to be created and fully signed before any of the spending tx can be created -- because they need the tx-hash for the 2-of-2 txout, which won't be available until all signatures are collected.
Yes, if Bob puts in a deposit it adds a step internally.

I think for this to have a reasonable user-interface Alice and Bob's bitcoin clients will need to communicate in real time.

My inclination is to add JSON-RPC methods to bitcoin-qt/bitcoind to support this, and not build it into bitcoin-qt's GUI (or at least not right away). I'm imagining Armory or little "let's make a deal" 2-party-escrow-apps that... Do The Right Thing.

Random UI thoughts:

Alice could be asked "How much do you trust Bob?"  and "How much do you think Bob trusts you?"  If an answer is "not at all" then propose an escrow that requires a substantial deposit.  If the answer is "a lot" then maybe no deposit is required. It'd be way spiffy cool if it was automagically tied into the #bitcoin-otc web of trust sytem...

(... more random thoughts: would IRC as the communication mechanism under the covers be a good or bad idea?  might be a convenient way to prototype...)

I'm imagining Bob gets the details of the proposed escrow and can either agree or disagree (maybe with a message to let Alice know what he WOULD agree to).

710  Bitcoin / Development & Technical Discussion / Re: Buyer-Seller Escrow Transactions (with or without 3rd-party) on: April 07, 2012, 12:57:07 AM
Getting help could cost more than the tx itself, and then Bob would just broadcast the LAZY_ALICE tx right away and get the money after 30 days knowing it's not worth it for Alice to try to figure it out.
Well, if DISPUTE is a fee-only transaction then miners have a VERY strong incentive to drop LAZY_ALICE and mine DISPUTE instead. I don't think we'd have trouble asking miners to support a code change that is something like:

Quote
If you get a transaction spending the same input as non-final (sequence number < max_sequence, lockTime in the future) transaction in your memory pool, then use the new transaction if it's got a (significantly) higher fee.

etotheipi, I've been thinking about your comment "I don't like the asymmetry" ...
LAZY_ALICE and DISPUTE are, I think, symmetric-- Alice holds DISPUTE in case Bob doesn't hold up his end of the bargain, Bob holds LAZY_ALICE in case she doesn't.  I proposed that DISPUTE have an earlier lockTime than LAZY_ALICE, but maybe that's not necessary.

If Alice really doesn't trust Bob, then I think the whole scheme also works if Bob puts a "good faith security deposit" of bitcoins into the mix.



The complexity of all this (5 possible transactions, different states the escrow can be in, initial communication to initiate the escrow) makes me nervous. Even just figuring out how Alice and Bob's clients talk to each to setup the escrow isn't obvious.
711  Bitcoin / Bitcoin Discussion / Re: Version 0.6.0 released on: April 07, 2012, 12:02:44 AM
Is anybody else seeing anything like what jetmine is seeing?  Anybody else running CentOS 5.6?  Did you compile from source or are you using the binaries we compiled?

My 0.6 nodes running on Ubuntu 11 have been rock solid.

The "CBlock::ReadFromDisk() : OpenBlockFile failed" is very odd, that should never happen.  You aren't running with a -datadir on a network drive or something are you?

RE: filling addr.dat:  that is one of the denial-of-service attacks fixed by the 0.6 release.
712  Bitcoin / Development & Technical Discussion / Re: Buyer-Seller Escrow Transactions (with or without 3rd-party) on: April 06, 2012, 04:06:20 PM
Gavin, where is your original proposal on multi-sig/escrow?  I want to look at it again now that I understand what's actually possible.

https://gist.github.com/830ca16758fb9ad496d7   : I created it as a 'private' gist because it is only half-baked.

RE: lockTime and the memory pool:

Note:  I'm using an "Alice pays Bob" scenario as described in the above gist:

If neither party is cheating, then the pre-signed DISPUTE  should NOT get broadcast until there really is a dispute. Instead, Alice and Bob's clients hold on to it.

So it is not in any miner's memory pools, and if there is no dispute nobody besides the two people involved in the transaction ever know about it.

Of course we have to assume that people WILL try to cheat, so the question becomes: what if Alice or Bob broadcasts DISPUTE prematurely?  Would anything bad happen?

I believe the answer is no, assuming Bob waits for transactions to be confirmed.  If DISPUTE is in "everybody's" memory pool, then any other transaction involving the escrowed funds will just be ignored. Even if Bob's client didn't see the DISPUTE broadcast (maybe he was offline) but later saw the SUCCESS transaction broadcast from Alice, SUCCESS would never be confirmed.

On the other hand, if not "everybody" has the DISPUTE transaction in their memory pool and Alice broadcasts SUCCESS, then it will likely be picked up by a miner and confirmed.  Once it is in a block, the conflicting DISPUTE transaction gets dropped from everybody's memory pool as a failed double-spend.  Given the churn in the nodes connected to the network, I expect this would actually be the most common case.

If Bob's client does see DISPUTE broadcast, it should probably let Bob know that Alice is unhappy and has disputed the transaction.

DISPUTE (which will be given a non-final sequence number) cannot get into a block until after lockTime.


All of the above is based on my best understanding of how the Satoshi code works right now; prototyping and experimenting on the testnet would be a good next step to make sure it actually behaves the way I think.
713  Bitcoin / Bitcoin Discussion / Re: The Royal Canadian Mint just announced a new alternative to BitCoin on: April 06, 2012, 12:01:29 AM
Well technicalities or not the point is that when User A is paying user B, user B is relying on the fact that user A "can't" break the chip.  The chip ensures security.  If User A has extracted private keys and can generate thousands or millions of duplicate tx at will there is nothing user B can do to detect that.  To user B chip the tx looks as valid as any other valid tx.  

If I'm reading their specs correctly, if A manages to break the chip she could generate duplicate transactions for the full value stored on the chip to B and C and D (and E and F and...).

But she wouldn't be able to double-spend the same funds to B, because B's chip is able to detect that attempted double-spend.

Eventually, I assume the Mint would figure out that the same funds were spent at B and C and D and... etc, just like the Mint eventually figures out when a lot of counterfeit paper notes are being spent in a particular area. And I imagine they'd deal with it the same way, interviewing merchants to ask them if they have a record of who made a transaction at a particular time, etc.

And assuming B/C/D/... did nothing wrong I bet the Mint honors all of the the A -> B/C/D/... transactions, so B/C/D/... don't lose any money. The Mint eats the loss (it just shows up as inflation in the money supply, so really EVERYBODY pays for the fraud), and if the problem gets large enough they declare version 1.0 of their chips obsolete and come out with a New and More Secure version.

It all looks pretty nifty to me, I hope it is a big success; it could be a great way to buy Bitcoins (non-reversible, cash-like...).
714  Bitcoin / Bitcoin Discussion / Re: Version 0.6.0 released on: April 05, 2012, 05:58:32 PM
This release is unstable as hell.  I get crashes.  I get unexpected exits.  And I get failures to restart.
All righty... you're the first person I've heard that from.

Please file bug reports on the github issue tracker. Include enough information so we can reproduce the problem (what platform? what seems to cause the problem? etc) and it might get fixed.

I say "might" because if you're serving up a big mining pool running bitcoind on Windows... well, none of the current core developers work on Windows.

715  Bitcoin / Development & Technical Discussion / Re: Buyer-Seller Escrow Transactions (with or without 3rd-party) on: April 05, 2012, 04:50:57 PM
In all cases: the Bitcoin network is acting as an escrow service -- and it's conditions are release are: "Wait for further instructions that are agreed upon by any two of these three people."  

BTW: I'm not proposing that this is the only way to escrow in the BTC network.  I would like to see some kind of time-locked tx that prevents laziness, and doesn't give one party too much power.  But I don't know how it can be done when tx-replacement isn't enabled on the network.

I think it is really important that the bitcoins involved in failed escrows not be destroyed, but EVENTUALLY make their way back into the economy.

So I'd really like to see network and client support for having both people pre-sign and hold on to a transaction with a far-in-the-future lockTime (maybe as a fee-only transaction).
716  Bitcoin / Development & Technical Discussion / Re: How-to disable wallet alerts ? on: April 03, 2012, 04:54:07 PM
edit2: @Gavin would you be so kind to write a patch for ver. 0.5.3 that makes alerts go off after a while, 5 minutes for ex.
Nope, sorry, have higher priority things to do.
717  Bitcoin / Development & Technical Discussion / Re: How-to disable wallet alerts ? on: April 03, 2012, 01:47:04 PM
Upgrade to 0.6.
718  Bitcoin / Bitcoin Discussion / Re: Multisignature ideas on: April 03, 2012, 12:39:39 AM
Multisignature adoption has to follow a multi-step process:

1. A majority of miners have to put multisignature transactions into blocks so they get confirmed.

2. A significant fraction of everybody else has to relay multisignature transactions so they reliably get to the miners (preferably more than 50%).

3. Depending on what you're using multisig FOR (escrow? secure wallets?), more technical infrastructure will need to be built.

4. After all of the above is done... y'all will be able to reliably use multisignature transactions.

April 1'st was the first step and we're doing pretty well with the second step, version 0.6 has a lot of support on the network already.  In fact, it is going so well I think we should turn on the 'addmultisigaddress' JSON-RPC method so people can start creating and experimenting with multisig with the 0.6.1 release.

719  Bitcoin / Development & Technical Discussion / Release plan (0.6.1 next) on: April 02, 2012, 03:38:22 PM
Summarizing a discussion from #bitcoin-dev this morning:

The merge window for pull requests for a 0.6.1 release is now open.

This will be a bug-fix and code-cleanup only release, with the goal to have Release Candidate 1 binaries available for testing in three weeks: April 23'rd.  We want this to be a quick release cycle so we can start pulling new features for a 0.7 release in a month or so.

The major issues I would like to get resolved:
 # 1024 Correct passphrase crashed the client
 # 1012 bitcoin-qt slow to shut down after recent commits

There are currently 189 open issues in our bug tracker; lets try to get that down to under 100.

I know this will frustrate some of you who think development is happening at a snail's pace; feel free to pull and test new features (IPv6 support and coin control) that are important to you. Adequate testing is still our biggest issue, if you want your favorite feature to get into bitcoin core faster please spend some time helping test other people's favorite features.
720  Bitcoin / Mining / Re: IMPORTANT: April 1 deadline for BIP16 support on: March 31, 2012, 11:41:22 PM
To Be(lieve) Or Not To Be, That Is The Question  Cheesy
About 20 minutes until the deadline... I expect to hear some very loud complaining about "I wasted a bunch of time generating orphan blocks why didn't you WARN me!" in the next few days. This is not an elaborate April Fool's joke.


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 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 ... 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!