Bitcoin Forum
October 17, 2021, 07:42:49 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 »
61  Bitcoin / Bitcoin Discussion / Re: The problem with transaction fees on: March 26, 2011, 09:08:53 PM
Consider a world where mining only pays out transaction fees. Almost all miners charge a transaction fee of t and all users pay a transaction fee of t on their transactions.

One miner decides to increase his profits by charging a smaller transaction fee. He publicly announces his intention and many users reduce their fee to be on par with the new fee he has announced.
If I post a transaction with a fee that would be accepted by only one miner, I will have to wait much longer for my transaction to get into a block. If he controlled 1% of the mining power, I'd have to wait for 100 blocks on average. That may not be attractive to many users.
62  Bitcoin / Development & Technical Discussion / Re: [RFD] All classes which use IMPLEMENT_SERIALIZE should check nVersion on reading on: March 25, 2011, 02:43:56 AM
I see why everyone's so confused about what I'm trying to discuss. I just realized the nVersion parameter to Serialize, GetSerialSize, and Unserialize is tied to the VERSION macro, and is basically a constant.
This is not quite right, but the code is pretty spread out. Generally un/serialization is done by the operator<< and operator>> methods of CDataStream in serialize.h. We do CTransaction tx; vRecv >> tx; to read a transaction object; or vSend << a1; to send something of template class a1 (in PushMessage in net.h).

The << and >> methods in CDataStream call Serialize() or Unserialize(), which do default the nVersion parameter to VERSION. But in these calls the default is not used, they pass the nVersion instance variable of CDataStream. And this instance variable is set to the min of the node and peer version, e.g. in the code I showed above.
63  Bitcoin / Development & Technical Discussion / Re: CreateNewBlock too slow (especially while bitcoin is under tx spam attack) on: March 24, 2011, 11:57:54 PM
Looking at the getwork code, it should only call CreateNewBlock() every minute or so:
Code:
       if (pindexPrev != pindexBest ||
            (nTransactionsUpdated != nTransactionsUpdatedLast && GetTime() - nStart > 60))
        {
[...]
            nTransactionsUpdatedLast = nTransactionsUpdated;
            pindexPrev = pindexBest;
            nStart = GetTime();

            // Create new block
            pblock = CreateNewBlock(reservekey);
This will call CreateNewBlock() either on a new block coming in, or on a new transaction if it's been 60 seconds since the last call. This shouldn't affect every getwork call, unless it's actually taking 60 seconds to do CreateNewBlock(), which would be remarkable.
64  Bitcoin / Bitcoin Discussion / Re: JavaScript UI for Bitcoin, QR code, bitcoin: URIs on: March 24, 2011, 07:47:47 PM
do i have to run the ssl server to use it locally?
The js-remote script implements a ssl web server, fully self contained. You don't need apache. Just run SSLserver.py, open up port 8338 for incoming, and connect with your mobile browser to https://yourhost.com:8338. Then you can access your wallet from anywhere, check balance, make payments, etc.
65  Bitcoin / Bitcoin Discussion / Re: What are the odds we'll find a collision by the time the last bitcoin gets mined? on: March 24, 2011, 07:39:06 PM
The person who originally had them would lose them.
66  Bitcoin / Bitcoin Discussion / Re: Use same wallet/address on multiple PCs? on: March 24, 2011, 07:37:16 PM
Warning, lots of bad information and wrong answers in this thread!

Addresses are not created in batches of 100 (after initialization), they are created one at a time as they are used, so you always have a pool of 100 unused addresses.

Wallets do hold transactions, all the ones you see in the client window.

You would probably not want to share the same wallet between your home system and your phone, because of the risk of theft, any more than you would empty your bank account and carry all your money around with you as cash. Most people plan to hold a fraction of their assets in their phones.

67  Bitcoin / Bitcoin Discussion / Re: What are the odds we'll find a collision by the time the last bitcoin gets mined? on: March 24, 2011, 07:19:43 PM
Adding a check for a sufficiently low probability event means that the overwhelming majority of the time, the CPU or memory glitched, and it is a false alarm.

Adding checks for address hash collisions with existing addresses would not protect you against the creation of an address in the future whose hash collides with yours.

If you ever did generate an address whose hash collided with an existing address, you could steal any bitcoins held by that address. So you might not want to throw this windfall away.
68  Bitcoin / Bitcoin Discussion / Re: Pros and cons of using new Bitcoin addresses for each transaction? on: March 24, 2011, 07:05:04 PM
I used to have trouble managing payments to a service that used a new address every time. Seems to conflict with the idea of an address book. Imagine if everyone's phone number changed every call. Not too convenient.

Here's what I do now:

1. Copy the payment address.
2. Choose Send Coins in the client.
3. Choose Address Book in the popup.
4. Choose New Address.
5. Enter a name for this payee, and paste in the Bitcoin address. Use the same name for all payments to this payee. For example, I use MBC for all transfers to my mybitcoin.com account.
6. Click OK in the New Address window.
7. Click OK in the Address Book window.
8. The Pay To field now holds the payment address. Enter the amount and click Send.

This way the transaction in your wallet will show who it's for. It does add some extra steps though. I wish sites would give customers the option to reuse a persistent address.
69  Bitcoin / Development & Technical Discussion / Re: [PATCH] bitcoin scratch-off cards on: March 23, 2011, 09:55:32 PM
If we are seriously considering putting this in the client, are there concrete plans to use this? Is someone committed to investing in making and selling scratchoff cards? Or is this patch useful for some other case that doesn't require such specialized equipment?
70  Economy / Economics / Re: How Does Stock Work on: March 23, 2011, 08:30:14 PM
The great majority of companies pay dividends, and that is what gives the stock its value.

New tech companies often don't pay dividends, but (believe it or not) their stock value comes from the expectation that they will pay dividends someday.

71  Economy / Economics / Re: Black Swan on MTGOX on: March 23, 2011, 08:18:12 PM
The buy-low-sell-high game only works when the market is trading in a narrow range. But you can't expect it to stay that way forever.
72  Bitcoin / Development & Technical Discussion / Re: [RFD] All classes which use IMPLEMENT_SERIALIZE should check nVersion on reading on: March 23, 2011, 08:01:59 PM
Specifically, what are you proposing? What nVersion value should they check, what should they check it against, and what should they do if the check fails/succeeds?

Messages do not have version numbers. Nodes exchange their client versions on connection, but that value increments with every release. There's no way to know if packets from a more-recent client peer have changed to be incompatible with this version.

Here is some of the code that handles the "version" message:
Code:
        // Change version
        if (pfrom->nVersion >= 209)
            pfrom->PushMessage("verack");
        pfrom->vSend.SetVersion(min(pfrom->nVersion, VERSION));
        if (pfrom->nVersion < 209)
            pfrom->vRecv.SetVersion(min(pfrom->nVersion, VERSION));

pfrom->nVersion is the peer version. This sends the "verack" message, checking if the peer is newer than version 209 for backwards compatibility. It sets the outgoing serialization version (vSend) to the older of the peer and this node, but only does it for incoming (vRecv) for peers older than 209. Otherwise the incoming deserialization version is left at this node; don't know why the difference.

This design puts the responsibility on the newer node to send/receive backwards compatible messages.
73  Other / Off-topic / Re: NEW: Bitcoin Fractional Reserve Bank on: March 23, 2011, 12:42:01 AM
You laugh, but I predict that fractional reserve Bitcoin banks will exist. They'll make loans and pay interest, just as banks have done for centuries.
74  Other / Off-topic / Re: Chase to end Debit Card Rewards on: March 23, 2011, 12:38:41 AM
At least is believable, unlike the ludicrous claim that they'd limit transactions to $100. That one was a transparent bluff.
75  Other / Off-topic / Re: Forum Membership Levels on: March 23, 2011, 12:35:08 AM
Kiba you're always looking for ways to earn btc, you should sell your user name. Bet you could get 100 btc for it.
76  Bitcoin / Project Development / Re: Bounty for Bitcoin Animated Movie [13622.05 BTC ($2520) and growing] on: March 23, 2011, 12:25:54 AM
Nice job! Sent 25 btc as thanks to 17eSZivDJpuJp9TxezTXVxkgLbsr3XZM1i.
77  Bitcoin / Bitcoin Discussion / Re: [RFC] Finite transaction lifetime (aka "fill or kill") on: March 22, 2011, 07:16:53 PM
From my understanding, it is in theory possible to "double spend" a transaction in limbo.  If the second attempt with a higher transaction fee makes it into a block, the first attempt will be interpreted as a double spending attempt by miners and simply be ignored.
A txn "in limbo" (in the transaction pool) will block double spends from being forwarded by peers, or accepted by (unhacked) miners. The pool is only in memory so gets wiped when the node is restarted, making network behavior somewhat nondeterministic. The wallet currently retransmits unconfirmed txns indefinitely, however the peers will not forward them unless/until the txns are cleared from peer memory due to a restart.
78  Bitcoin / Development & Technical Discussion / Re: Wallet import/export: bitkeys format on: March 21, 2011, 06:30:23 PM
Simply by adding reserve keys (which are in fact harder to filter out when exporting, since they are available in mapKeys like change keys and used keys), you have everything to have a bitkeys file function as a backup or by limiting its contents, as an interchange format.
There's other stuff in wallets, including preferences, address book entries for payees, and account information. bitkeys format won't be suitable for wallet backup if it loses all this.
79  Bitcoin / Bitcoin Discussion / Bitcoin == terrorism? on: March 20, 2011, 06:52:34 PM
Here is the government press release on the Liberty Dollar case:

http://charlotte.fbi.gov/dojpressrel/pressrel11/ce031811.htm

Quote
“Attempts to undermine the legitimate currency of this country are simply a unique form of domestic terrorism,” U.S. Attorney Tompkins said in announcing the verdict. “While these forms of anti-government activities do not involve violence, they are every bit as insidious and represent a clear and present danger to the economic stability of this country,” she added. “We are determined to meet these threats through infiltration, disruption, and dismantling of organizations which seek to challenge the legitimacy of our democratic form of government.”

I worry that Bitcoin can be seen as even more of a threat to the supremacy of the dollar, which by this reasoning would make it terrorism. An extreme claim, to be sure, but apparently the U.S. Is willing to go there.

The government also advances this theory:

Quote
Article I, section 8, clause 5 of the United States Constitution delegates to Congress the power to coin money and to regulate the value thereof. This power was delegated to Congress in order to establish and preserve a uniform standard of value and to insure a singular monetary system for all purchases and debts in the United States, public and private. Along with the power to coin money, Congress has the concurrent power to restrain the circulation of money which is not issued under its own authority in order to protect and preserve the constitutional currency for the benefit of all citizens of the nation. It is a violation of federal law for individuals, such as von NotHaus, or organizations, such as NORFED, to create private coin or currency systems to compete with the official coinage and currency of the United States.

Now this is really stretching the truth. Until the Civil War era, there was no U.S. currency as such, rather paper money was issued, perfectly legally, by private banks. There is no Constitutional prohibition of private currency. There is a law that prohibits private metallic coins, 18 USC 486, which is what they used against LD. It's ominous to see the U.S. expanding its claims like this, to the point where they would cover Bitcoin.
80  Bitcoin / Development & Technical Discussion / Re: [PATCH] bitcoin scratch-off cards on: March 19, 2011, 07:37:21 PM
The modification to repeatedly hash the 64 bit password is a good idea, and should prevent square root attacks. I would probably have used a simpler iterative formula, but that one seems safe enough. SHA512 is notorious for speed variations on different architectures, but compared to the time to type in the password, that should be ok. Where does the magic number 108333 come from?
Pages: « 1 2 3 [4] 5 6 7 8 9 10 11 12 13 14 15 16 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!