Bitcoin Forum
November 17, 2025, 04:30:11 PM *
News: Latest Bitcoin Core release: 30.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 [3] 4 »
41  Bitcoin / Bitcoin Discussion / Re: bitcoincard.org on: April 26, 2012, 09:33:13 PM
Hate the dumbed down nature of the video (do you really need to explain "credit-card size" so much).  The only thing you need is a smart card, like the openPGP card, that stores a small wallet in secured storage and that can make transactions.  (Wallet on smart card can be smallish and should be backed up to your desktop so you can move money on and off the card)
Here is how it would work:
1) POS terminal connects to smartcard telling it the amount and the address to send to
2) Smartcard makes transaction and gives it back to the POS terminal (smartcard could be made with a small display for amount and a confirm button so user could verify request before proceeding)
3) POS terminal verifies that it is valid (inputs have the necessary amounts to cover outputs, etc) and uploads transaction to Bitcoin network
4) Profit!  <-- Literally
42  Bitcoin / Development & Technical Discussion / Re: Automatic Fee Calculation on: April 22, 2012, 05:46:10 AM
It would also be nice if the client actively tried to create transactions with the smallest possible fee.  Right now inputs are selected at random so that you could get different fees.
43  Bitcoin / Development & Technical Discussion / Re: Bitcoin smartcard Point of Sale terminal on: April 19, 2012, 04:51:55 PM
Did a little search and BasicCard looks promising.  It seems to have ECC and SHA-256 built-in.  Look for version ZC7.5
http://www.basiccard.com/index.html
44  Bitcoin / Development & Technical Discussion / Re: Bitcoin smartcard Point of Sale terminal on: April 19, 2012, 04:33:01 PM
Ideally, you would want the private key to never leave the card.  Therefore the card would have to be able to generate a transaction and give it to the terminal to upload to the network.  The terminal could then verify the transaction (check address balance and that there are no other transactions pending that would drop the balance) and release the sale.  I think there may be an issue since you would need the code for ECC, SHA256 and RIPE160 (that is a lot of code).  But I don't think storing keys would be to much of a problem.  You would only need a hand full of addresses and each is only about 64 bytes each (I think, someone correct me).  You could always switch out which keys are on the card for anonymity.

Edit:  I just remembered that you could possibly remove one of the hash functions since transactions are a kind of script.  You could change it so that the public key is only hashed with SHA256 or RIPE160 instead of both.  But to do that most nodes would need to be updated to recognize that kind of transaction, since the scripting functions are not complete.
45  Bitcoin / Mining speculation / Re: What happens when the coins dry up? on: April 19, 2012, 02:31:21 AM
The thing that will happen is that people with dedicated rigs will start pulling out as block rewards drop.  But on the flip side difficultly will also drop.  Once the block reward drops enough (and the difficultly with it) you would see more people solo mining (outside of pools).  The first drop in block reward (and I believe bitcoin's first real test of longevity) will be in this December.  The thing to watch is how the total hashrate and difficultly and how quickly.  I think there is a built in max change in difficultly of 400% up or down.  As long as the total hashrate doesn't drop too much faster than difficultly, you wouldn't notice a thing.  Also, as long as there isn't a sustained exudes of people from the community, you could expect the price for coins to rise (slowly) as people turn to buying coins instead of mining.
46  Bitcoin / Wallet software / Why not pull transaction data from blockexplorer? on: April 19, 2012, 02:19:07 AM
I was wondering why you couldn't just pull the transaction data from blockexplorer.com (https://blockexplorer.com/q/mytransactions/{address_here}) so that thin/mobile clients didn't have to download and possible store the blockchain themselves.  I'm sure whoever is running blockexplorer might not want all the extra traffic, but you could use a similar model to setup a dedicated server for it if needed.
47  Bitcoin / Wallet software / Re: BitPak - The Bitcoin Wallet for iOS on: April 19, 2012, 02:14:07 AM
Instead of downloading the whole blockchain could you just query https://blockexplorer.com/q/mytransactions/{address_here} and get the transactions?
48  Bitcoin / Development & Technical Discussion / Re: Bitcoin Poker Chip / Physical Coin on: April 19, 2012, 02:03:55 AM
You could use smart cards like the OpenPGP card.  The private/public keys are generated right on the card and it is impossible to get the private key out.  Also the creation of the transaction could happen on the smart card.
49  Bitcoin / Development & Technical Discussion / Re: what is going on with testnet network? on: April 17, 2012, 06:25:20 PM
It seems to me that no one is really mining on the testnet so it would seem that there are also very few nodes and maybe few have the whole blockchain.  I'm playing around with around with the script functions and if I want blocks to be made I've had to mine them myself.  The current rate seems to be making blocks every few hours, unless someone like me is actively doing something.
50  Bitcoin / Development & Technical Discussion / Re: Bounty proposal for a Bitcoin-based email to fight spam. on: April 12, 2012, 09:46:34 PM
I see the problem being that bitcoin values are to volatile.  It is the same problem with decided what is the best transaction fee.  One month 0.01 BTC could be equal to $0.01 but later in the year it could be closer to $1.00. 
51  Bitcoin / Development & Technical Discussion / Re: Milestone Block Idea on: April 12, 2012, 09:41:01 PM
Here is my idea.  Every year (or every 52560 blocks) create a special milestone block that contains all the bitcoin addresses and their balances and get that inserted/mined into the block chain.  This would allow you to remove the all blocks before that special block from disk/memory.  I think ideally you might want to keep at least two milestone blocks to keep some history.  This plan also offers the opportunity to reclaim some lost coins.  You could declare any address that has no activity in 1 or 2 years as abandoned and award them to the miner who mined the milestone block.

I think you meant to post this here:
www.highdeas.com
Why?  What is wrong with the idea?  One of the issues with bitcoin is the growing size of storing the whole, ever growing, blockchain.  With my idea you could keep it from growing forever.
52  Bitcoin / Development & Technical Discussion / Milestone Block Idea on: April 12, 2012, 05:34:29 PM
Here is my idea.  Every year (or every 52560 blocks) create a special milestone block that contains all the bitcoin addresses and their balances and get that inserted/mined into the block chain.  This would allow you to remove the all blocks before that special block from disk/memory.  I think ideally you might want to keep at least two milestone blocks to keep some history.  This plan also offers the opportunity to reclaim some lost coins.  You could declare any address that has no activity in 1 or 2 years as abandoned and award them to the miner who mined the milestone block.
53  Bitcoin / Development & Technical Discussion / Re: Synchronizing with Blockchain I/O bound on: March 22, 2012, 03:27:33 AM
What about changing how the database is stored on disk?  It seems to me that using the Berkeley DB library might be causing the problem, but I don't know enough on how that works to be sure.  Maybe using some other database library (like SQLite) would have less disk IO.
54  Bitcoin / Development & Technical Discussion / Re: Miners that refuse to include transactions are becoming a problem on: March 22, 2012, 03:22:46 AM
Why not put in a requirement of at least 1 valid transaction for a block to be valid?  If there are no pending transactions then there is a bigger problem happening.  You would just have to be very clear on what is a valid transaction to prevent penny spamming and such.
55  Bitcoin / Bitcoin Discussion / Re: Ways for governments to ruin Bitcoin on: April 18, 2011, 12:05:18 AM
The easiest way would be for governments to buy/mine bitcoins and keep them out of the circulation.
56  Bitcoin / Pools / Re: [~100 Gh/s Mining Pool] INSTANT PAYOUT,+1% with LP! +0.8% for no failed blocks! on: April 13, 2011, 07:50:50 PM
I've seen a few fourm post about transaction fees vs free transaction and I was wondering if your server is running using the current standard rules about fees or if you have modified it to accept certain transactions over others?

(I'm not trying to accuse you of anything, just curious.)
57  Bitcoin / Development & Technical Discussion / Re: [RFD] Coin selection algorithm and anonymity on: April 11, 2011, 07:12:11 PM
Ok, so I've worked on this a little for you.

I took the SelectCoinsMinConf function in main.cpp and changed it to match your descriptions, so I have SelectCoins1Conf, SelectCoins2Conf,  and SelectCoins3Conf (4 is going to take a little more work to keep the transactions small).  These functions are called in the SelectCoins function.  I'm not completely sure what the variables nConfMine and nConfTheirs but they seem to have to do with how deep the transactions are in the block chain, so I haven't really messed with them.

Look at the attached file below (can't get a file to attach; upload folder is full) it is just has the new functions and the changed SelectCoins function.  Tell me what you think.  I haven't had time to test this.  I'll have to setup something for the testnet.


Code:
/*
Select a coin which is exactly twice the value of the payment
This makes the two outputs identical, making it impossible to guess which is the payment and which is
the change. Variations: select two or more coins that total exactly twice the payment amount; select
one coin which is approximately twice the payment amount (this will result in two outputs which are close
in value, and as shown above you cannot reliably guess which is the payment)
*/

// Look for a coin that is within 10% of twice the right size
bool SelectCoins1Conf(int64 nTargetValue, int nConfMine, int nConfTheirs, set<CWalletTx*>& setCoinsRet)
{
setCoinsRet.clear();

CRITICAL_BLOCK(cs_mapWallet)
{
vector<CWalletTx*> vCoins;
vCoins.reserve(mapWallet.size());

for (map<uint256, CWalletTx>::iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
vCoins.push_back(&(*it).second);
random_shuffle(vCoins.begin(), vCoins.end(), GetRandInt);

foreach(CWalletTx * pcoin, vCoins)
{
if (!pcoin->IsFinal() || pcoin->fSpent || !pcoin->IsConfirmed())
continue;

int nDepth = pcoin->GetDepthInMainChain();

if (nDepth < (pcoin->IsFromMe() ? nConfMine : nConfTheirs))
continue;

int64 n = pcoin->GetCredit();

if (n <= 0)
continue;

if (n == nTargetValue)
{
setCoinsRet.insert(pcoin);
return(true);
}else if ((n == (2 * nTargetValue)) ||
 (n >= (1.9 * nTargetValue)) ||
 (n <= (2.1 * nTargetValue)))
{
setCoinsRet.insert(pcoin);
return(true);
}
}
}

return(false);
}

/*
Select two coins such that either (a) the value of each input is less than the payment amount and
sums to greater than (but NOT equal to) the payment amount, or (b) the value of each input is greater
than the payment amount

Example:
A=4, B=2, O1=5, O2=1

A tracker looking at this transaction cannot tell if it satisfies condition (a) or condition
(b), therefore they cannot determine which is the payment and which is the change.
For condition (a), O1 is the payment, and for condition (b) O2 is the payment.
*/
bool SelectCoins2Conf(int64 nTargetValue, int nConfMine, int nConfTheirs, set<CWalletTx*>& setCoinsRet)
{
setCoinsRet.clear();

CRITICAL_BLOCK(cs_mapWallet)
{
vector<CWalletTx*> vCoins;
vCoins.reserve(mapWallet.size());

size_t pCount = 0;

for (map<uint256, CWalletTx>::iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
{
vCoins.push_back(&(*it).second);
++pCount;
}
random_shuffle(vCoins.begin(), vCoins.end(), GetRandInt);

CWalletTx* pfoundlargercoin1 = NULL;

CWalletTx* smaller_coins[pCount];
size_t smaller_count = 0;
int64 smaller_value = 0;

foreach(CWalletTx * pcoin, vCoins)
{
if (!pcoin->IsFinal() || pcoin->fSpent || !pcoin->IsConfirmed())
continue;

int nDepth = pcoin->GetDepthInMainChain();

if (nDepth < (pcoin->IsFromMe() ? nConfMine : nConfTheirs))
continue;

int64 n = pcoin->GetCredit();

if (n <= 0)
continue;

if (n > nTargetValue)
{
if (pfoundlargercoin1 == NULL)
{
pfoundlargercoin1 = pcoin;
continue;
} else
{
setCoinsRet.insert(pfoundlargercoin1);
setCoinsRet.insert(pcoin);
return(true);
}
} else if (n < nTargetValue)
{
smaller_coins[smaller_count++] = pcoin;
smaller_value += n;
}
}
if (smaller_value < nTargetValue ||
smaller_value == nTargetValue && smaller_count < 2)
return(false);
for (int iLoop1 = 0; iLoop1 < smaller_count; ++iLoop1)
{
for (int iLoop2 = iLoop1; iLoop2 < smaller_count; ++iLoop2)
{
if (smaller_coins[iLoop1]->GetCredit() + smaller_coins[iLoop2]->GetCredit() >= nTargetValue)
{
setCoinsRet.insert(smaller_coins[iLoop1]);
setCoinsRet.insert(smaller_coins[iLoop2]);
return(true);
}
}
}
}

return(false);
}

/*
Select two coins: one whose value exactly matches the payment, and another coin at random.
Example:
A=5, B=2; O1=5, O2=2

It's rather obvious what we're doing here, but since we (and the tracker) know the payment and
change are randomized, a tracker cannot know which is the payment and which is the change.
*/
bool SelectCoins3Conf(int64 nTargetValue, int nConfMine, int nConfTheirs, set<CWalletTx*>& setCoinsRet)
{
setCoinsRet.clear();

CRITICAL_BLOCK(cs_mapWallet)
{
vector<CWalletTx*> vCoins;
vCoins.reserve(mapWallet.size());

size_t pCount = 0;

for (map<uint256, CWalletTx>::iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
{
vCoins.push_back(&(*it).second);
++pCount;
}
random_shuffle(vCoins.begin(), vCoins.end(), GetRandInt);

CWalletTx* smaller_coins[pCount];
size_t smaller_count = 0;
int64 smaller_value = 0;

CWalletTx* pfrandomcoin = NULL;
CWalletTx* pexactcoin = NULL;

foreach(CWalletTx * pcoin, vCoins)
{
if (!pcoin->IsFinal() || pcoin->fSpent || !pcoin->IsConfirmed())
continue;

int nDepth = pcoin->GetDepthInMainChain();

if (nDepth < (pcoin->IsFromMe() ? nConfMine : nConfTheirs))
continue;

int64 n = pcoin->GetCredit();

if (n <= 0)
continue;

if (n == nTargetValue)
{
pexactcoin = pcoin;

}
else
pfrandomcoin = pcoin;

if (pexactcoin != NULL && pfrandomcoin != NULL)
{
setCoinsRet.insert(pexactcoin);
setCoinsRet.insert(pfrandomcoin);
return(true);
}
}
}

return(false);
}
/*
A special variation on (1) (I call this one the "In yo face!" selection): Select multiple coins adding
to more than the payment amount, and if possible ensure at least one coin is redundant.
Example:
A=2, B=3, C=1, D=1, E=2, O1=4, O2=5

It's clear from examining this transaction that several combinations of the coins could satisfy either
O1 or O2, so the tracker cannot tell which is the payment and which is the change. Note that this algorithm,
unlike the others, is guaranteed to find a set of coins that can be used.
*/
bool SelectCoins4Conf(int64 nTargetValue, int nConfMine, int nConfTheirs, set<CWalletTx*>& setCoinsRet)
{
setCoinsRet.clear();

CRITICAL_BLOCK(cs_mapWallet)
{
vector<CWalletTx*> vCoins;
vCoins.reserve(mapWallet.size());

size_t pCount = 0;

for (map<uint256, CWalletTx>::iterator it = mapWallet.begin(); it != mapWallet.end(); ++it)
{
vCoins.push_back(&(*it).second);
++pCount;
}
random_shuffle(vCoins.begin(), vCoins.end(), GetRandInt);

CWalletTx* smaller_coins[pCount];

CWalletTx* pfoundlargercoin1 = NULL;
size_t smaller_count = 0;
int64 smaller_value = 0;

foreach(CWalletTx * pcoin, vCoins)
{
if (!pcoin->IsFinal() || pcoin->fSpent || !pcoin->IsConfirmed())
continue;

int nDepth = pcoin->GetDepthInMainChain();

if (nDepth < (pcoin->IsFromMe() ? nConfMine : nConfTheirs))
continue;

int64 n = pcoin->GetCredit();

if (n <= 0)
continue;

if (n > nTargetValue)
{
if (pfoundlargercoin1 == NULL)
{
pfoundlargercoin1 = pcoin;
continue;
} else
{
setCoinsRet.insert(pfoundlargercoin1);
setCoinsRet.insert(pcoin);
return(true);
}
} else if (n < nTargetValue)
{
smaller_coins[smaller_count++] = pcoin;
smaller_value += n;
}
}
if (smaller_value < nTargetValue ||
smaller_value == nTargetValue && smaller_count < 2)
return(false);
for (int iLoop1 = 0; iLoop1 < smaller_count; ++iLoop1)
{
for (int iLoop2 = iLoop1; iLoop2 < smaller_count; ++iLoop2)
{
if (smaller_coins[iLoop1]->GetCredit() + smaller_coins[iLoop2]->GetCredit() >= nTargetValue)
{
setCoinsRet.insert(smaller_coins[iLoop1]);
setCoinsRet.insert(smaller_coins[iLoop2]);
return(true);
}
}
}
}

return(false);
}

bool SelectCoins(int64 nTargetValue, set<CWalletTx*>& setCoinsRet)
{
return (SelectCoins2Conf(nTargetValue, 1, 6, setCoinsRet) ||
SelectCoins1Conf(nTargetValue, 1, 6, setCoinsRet) ||
SelectCoins3Conf(nTargetValue, 1, 6, setCoinsRet) ||
SelectCoinsMinConf(nTargetValue, 1, 6, setCoinsRet) ||
SelectCoins2Conf(nTargetValue, 1, 1, setCoinsRet) ||
SelectCoins1Conf(nTargetValue, 1, 1, setCoinsRet) ||
SelectCoins3Conf(nTargetValue, 1, 1, setCoinsRet) ||
SelectCoinsMinConf(nTargetValue, 1, 1, setCoinsRet) ||
SelectCoins2Conf(nTargetValue, 0, 1, setCoinsRet) ||
SelectCoins1Conf(nTargetValue, 0, 1, setCoinsRet) ||
SelectCoins3Conf(nTargetValue, 0, 1, setCoinsRet) ||
SelectCoinsMinConf(nTargetValue, 0, 1, setCoinsRet));
}
58  Bitcoin / Development & Technical Discussion / Re: Is A Javascript Based Miner At All Possible? on: April 04, 2011, 05:18:25 PM
Most browsers have a limit for how long a script can run when you load a page.  I think about 30 seconds.
59  Bitcoin / Bitcoin Discussion / Lottery idea on: April 01, 2011, 05:41:48 PM
People send in, say, 5 bitcoins to a server, who then sends out several transactions, one for each participant sending all the bitcoins (minus a small fee) to them,  Winner is decided by which transaction is successfully added to the new block.
60  Bitcoin / Bitcoin Technical Support / Re: Can my Bitcoins be stolen? on: April 01, 2011, 05:07:50 PM
What if someone else just so happens to randomly generate the same keypair and someone else?  Like what if someone where to setup their machine to do nothing but generate keypairs until they found one that matched an account with coins in it?  Hell, while your at it, same all the keypairs you make and check them periodically for matches.
Pages: « 1 2 [3] 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!