Search content
Sort by
Showing 20 of 57 results by commonancestor
Re: [VOTE] ISO Currency Code bringing Bitcoin into the mainstream financial markets
I would propose these currency codes:
XBT for Bitcoin
XBM for milliBitcoin
XBN for microBitcoin
Some may get officially registered by ISO, some may not.
Using smaller denominations makes sense as it is common to use 2 fractional digits in amounts.
XBT for Bitcoin
XBM for milliBitcoin
XBN for microBitcoin
Some may get officially registered by ISO, some may not.
Using smaller denominations makes sense as it is common to use 2 fractional digits in amounts.
Specifications aren't magic; they're just words on paper. I can put anything into a specification, but it doesn't magically make code actually follow the spec. I can also take the specification and write tests, but again, the tests don't magically make the code follow the specification.
Before commenting further on the topic you need to read the Bitcoin sourcecode yourself. If you can't read it, you have no business commenting on software development anyway. If you can, you'll find that while it isn't perfect and could use some refactorings, all in all understanding the intent of the different parts is fairly easy and thus the code itself acts as a perfectly good specification.
Before commenting further on the topic you need to read the Bitcoin sourcecode yourself. If you can't read it, you have no business commenting on software development anyway. If you can, you'll find that while it isn't perfect and could use some refactorings, all in all understanding the intent of the different parts is fairly easy and thus the code itself acts as a perfectly good specification.
You are right, I should read the code indeed. A protocol defined in the code rather than in a specification - pros: no maintenance effort, no ambiguity (in theory); cons: difficult to read and understand, difficult to make other implementations (including new versions of the same program). The blockchain fork happened because devs forgot that Berkeley DB was part of the protocol. Without reading the code I find this bit messy.
How about no? Making it 10MB would just necessitate another hard fork in the future. We should have as few hard forks as possible, so make it dynamic somehow so that that part of the protocol need not ever be changed again.
One of the key elements of Bitcoin is decentralization via the P2P network. Average Joe needs to be able to run a full node. In my opinion 10MB blocks (some 100MB per hour) are acceptable for average Joe these days, but 100MB blocks (some 1GB per hour) are bit too much now (maybe ok in 1-2 years). Unfortunately there is no reliable indicator for Bitcoin to know what are current network speeds and hard-disk sizes. If tying it to past results, big miners could game such system. I can't see any good dynamic solution. Imho if it can have one hard fork now, then it can have another after 1-2 years. Everybody understands what replacing 1MB with 10MB means, it's no rocket science.
How easy / hard would it be to change this limit? It seems, this function controls how many coins are given to miners for solving a block. If developers decided to change this function, the 21 million number would change too, right? Or is the 21 million number somehow coded deeper in the system?
If there is a block containing larger-than-standard reward, it is rejected by standard nodes. If there are some non-standard nodes who accept it, then they effectively create a blockchain fork, and onwards they are on their own.
Or a different point of view, it would take a hard fork with all it takes.
Certainly from a software engineering point of view, medium-term scalability is a trivial problem. An extra zero in the
Code:
static const unsigned int MAX_BLOCK_SIZE = 1000000;
line would be fine for a good while.Yes please, 10 megabyte per block is the right answer.
Also 100 MB may be considered in the future, but for some users it would be lots of traffic these days.
Also it would be nice to have the old tx pruning function some day as the database starts growing faster.
So... what happens then? What is the method for implementing a hard fork? No precedent, right? Do we have a meeting? With who? Vote? Ultimately its the miners that get to decide, right? What if the miners like the 1MB limit, because they think the imposed scarcity of blockchain space will lead to higher transaction fees, and more bitcoin for them? How do we decide on these things when nobody is really in charge? Is a fork really going to happen at all?
Actually there is a hard fork in progress right now: there is a database locking glitch in <=v0.7.2 so everyone needs to upgrade to v0.8.1 by 15/May/2013.
Increasing block size does not seem significantly different.
First there is selected a block number from which the increased block size applies. For example block >=261840 which is expected around Oct 2013.
Then - few months before Oct 2013 - this logic is implemented in the full-node clients - Satoshi client, bitcoinj, ... - and people are asked to upgrade, or have their old clients stop working after Oct 2013.
That's all.
Devs,
1. Thanks for getting us over this glitch safely.
2. It is beyond belief that validity of a block could be decided by such implementation specific matters like BerkeleyDB record locking.
And, of course, there is no specification of what is a valid block. The code is the specification? So make no changes to the code and we won't have forks?
Please take the code at some point and write the specification of what is a valid block. Then change the code as you like and test if it's ok with the specs.
Also you may find out that the block validity rules are too weird and could refactor them better.
As Mike Hearn says, money could be lost here.
1. Thanks for getting us over this glitch safely.
2. It is beyond belief that validity of a block could be decided by such implementation specific matters like BerkeleyDB record locking.
And, of course, there is no specification of what is a valid block. The code is the specification? So make no changes to the code and we won't have forks?
Please take the code at some point and write the specification of what is a valid block. Then change the code as you like and test if it's ok with the specs.
Also you may find out that the block validity rules are too weird and could refactor them better.
As Mike Hearn says, money could be lost here.
Re: Soft block size limit reached, action required by YOU
We are already bumping up against a limit. No simulation needed. We have reality instead ...
OK, wrong word. Still I hope that most pools will not immediately lift / increase their limit. So we know what will happen when we reach the hard limit, which can't be changed so easily.
So let us bump against this for a few month. And lift it only if it really damages Bitcoin.
Yes, this is the right approach. Solve the problem now soft way, rather than later hard way.
I think the solution should be increasing both tx fees and max block size. The network should not discriminate against users based on who they are (e.g. SatoshiDice). If it's possible to flood the network with cheap transactions then the fees are simply too low and should be increased. Also miners should be less dependent on generating coins and more on receiving fees. When the fee is "about right" and blocks are getting full then increase max block size. It should be such so that average Joe can still run his full node or a miner.
So, can we get a straight answer?
JoelKatz can I have your personal opinions on the speculation going on with XRP right now (see my example quotes)?
Unfortunately, no. I am prohibited from discussing that. Those things that I cannot comment honestly on for any reason, I simply do not discuss. There's nothing I enjoy more than sharing my honest opinions with others, but in this area, I cannot do so.JoelKatz can I have your personal opinions on the speculation going on with XRP right now (see my example quotes)?
Is this a joke? lol
Hi, thank you for the answers.
So bitstamp doesn't have any special privileges in the system. Ok.
So if I get it right, when making payments the system values my 1 BTC IOU the same as my friend's 1 BTC IOU. Not ok.
It's meant be the complicated way so when a payment goes through the users, they get exchanged also debts in the same currency at arbitrary rates.
No, I just placed an exchange order for buying BTC, it got executed, and I received BTC - without any trust to the issuer. I didn't really mind but it seems it goes around the limits.
But somehow I can image some people doing so, thinking like how they are gaming the system.
Anyway, as we discussed elsewhere, there is this XRP currency which is an element outside of ripple, and which ripple traditionalists can't wrap their heads around.
But you can do most of what a gateway does without being a gateway.
So bitstamp doesn't have any special privileges in the system. Ok.
In some cases they are treated as the same currency, in some cases they are treated differently. The system does allow you to value IOUs in the same currency but different issuers differently, but this is a very tricky feature to use correctly. The main difference is this: To change the issuer of an IOU but not the currency, you can ripple through someone. To change the currency, whether or not you change the issuer, you must take one or more offers.
So if I get it right, when making payments the system values my 1 BTC IOU the same as my friend's 1 BTC IOU. Not ok.
It's meant be the complicated way so when a payment goes through the users, they get exchanged also debts in the same currency at arbitrary rates.
I think the scenario you're envisioning is this: ...
No, I just placed an exchange order for buying BTC, it got executed, and I received BTC - without any trust to the issuer. I didn't really mind but it seems it goes around the limits.
... this is *not* a good idea.
But somehow I can image some people doing so, thinking like how they are gaming the system.
Anyway, as we discussed elsewhere, there is this XRP currency which is an element outside of ripple, and which ripple traditionalists can't wrap their heads around.
I have got a similar opinion like OP.
Ripple.com is a mix of Bitcoin-like currency XRP and ripple IOUs. As XRP is more suitable for payments than IOUs, it seems that IOUs would become only a secondary feature, and so it seems unfair to call this system Ripple. The difference from Bitcoin would be no mining, but starting a new server would be more troublesome because the peer has to find some (many?) peers that he would trust not to cheat him, ideally some peers he knows.
How about True Ripple? I can think of a system with just IOUs without XRP. It would also be truly P2P. There wouldn't be the global ledger but just peers transacting with (few) peers they know. All value transfer would be performed using chains of IOU transfers between peers, obviously. To prevent spamming there would be fees for all activities using up resources, like routing a search through a node, or routing a payment through a node. If a node sets fees too high then the traffic would route through someone else eventually. The actual interaction between nodes would need to be somewhat cautious, so the money don't disappear on a half-way, but it seems doable.
Ripple.com is a mix of Bitcoin-like currency XRP and ripple IOUs. As XRP is more suitable for payments than IOUs, it seems that IOUs would become only a secondary feature, and so it seems unfair to call this system Ripple. The difference from Bitcoin would be no mining, but starting a new server would be more troublesome because the peer has to find some (many?) peers that he would trust not to cheat him, ideally some peers he knows.
How about True Ripple? I can think of a system with just IOUs without XRP. It would also be truly P2P. There wouldn't be the global ledger but just peers transacting with (few) peers they know. All value transfer would be performed using chains of IOU transfers between peers, obviously. To prevent spamming there would be fees for all activities using up resources, like routing a search through a node, or routing a payment through a node. If a node sets fees too high then the traffic would route through someone else eventually. The actual interaction between nodes would need to be somewhat cautious, so the money don't disappear on a half-way, but it seems doable.
Hi there, it seems like a nice system. I have got couple of questions though.
1. Are there implemented any special rules for gateways, or is this just something that everyone can do?
2. Is BTC issued by A and B the same currency? As they may have different exchange rates, I think they are different. But it seems that when a payment goes through the system, they are treated as the same BTC, right? Or are users supposed to set exchange rates between various BTC? Probably they should; e.g. if I think that BTC issued by me are much safer than BTC issued by my friend, then as a payment goes through us, I would only agree to issue 0.9 BTC for receiving 1 BTC issued from him. What are the intentions about this?
3. What happens if there is a debt but no trust limit? I managed to buy some BTC but without extending a trust limit to theseller issuer first. Also it appears that some orders could be created with similar results. Other way to get into this situation is possibly to remove the limit after the debt exists. Shouldn't this be restricted somehow? Or should it be not restricted and the trust limits would only be informative? Actually why should I pressure friends about settling their debts at all? It may be something about that they can't pay me anymore, but hey, I could extend their trust limit further coz it's just a number?
1. Are there implemented any special rules for gateways, or is this just something that everyone can do?
2. Is BTC issued by A and B the same currency? As they may have different exchange rates, I think they are different. But it seems that when a payment goes through the system, they are treated as the same BTC, right? Or are users supposed to set exchange rates between various BTC? Probably they should; e.g. if I think that BTC issued by me are much safer than BTC issued by my friend, then as a payment goes through us, I would only agree to issue 0.9 BTC for receiving 1 BTC issued from him. What are the intentions about this?
3. What happens if there is a debt but no trust limit? I managed to buy some BTC but without extending a trust limit to the
Re: How a floating blocksize limit inevitably leads towards centralization
Interesting debate.
I tend to agree with Pieter.
First of all, the true nature of Bitcoin seems to be the rigid protocol as it helps the credibility among masses. Otherwise one day you remove block size limit, next day remove ECDSA, then change block frequency to 1 per minute, then print more coins. It actually sounds more appropriate to do such changes under a different implementation.
Then I can't help this: With such floating block limit isn't everyone afraid of chain splits? I can imagine a split occurring by a big block being accepted by 60% of the nodes and rejected by the rest.
This sounds interesting.
First of all, my opinion: I'm in favor of increasing the block size limit in a hard fork, but very much against removing the limit entirely. Bitcoin is a consensus of its users, who all agreed (or will need to agree) to a very strict set of rules that would allow people to build global decentralized payment system. I think very few people understand a forever-limited block size to be part of these rules.
...
My suggestion would be a one-time increase to perhaps 10 MiB or 100 MiB blocks (to be debated), and after that an at-most slow exponential further growth. This would mean no for-eternity limited size, but also no way for miners to push up block sizes to the point where they are in sole control of the network. I realize that some people will consider this an arbitrary and unnecessary limit, but others will probably consider it dangerous already. In any case, it's a compromise and I believe one will be necessary.
Realize that Bitcoin's decentralization only comes from very strict - and sometimes arbitrary - rules (why this particular 50/25/12.5 payout scheme, why ECDSA, why only those opcodes in scripts, ...) that were set right from the start and agreed upon by everyone who ever used the system. Were those rules "central planning" too?
...
My suggestion would be a one-time increase to perhaps 10 MiB or 100 MiB blocks (to be debated), and after that an at-most slow exponential further growth. This would mean no for-eternity limited size, but also no way for miners to push up block sizes to the point where they are in sole control of the network. I realize that some people will consider this an arbitrary and unnecessary limit, but others will probably consider it dangerous already. In any case, it's a compromise and I believe one will be necessary.
Realize that Bitcoin's decentralization only comes from very strict - and sometimes arbitrary - rules (why this particular 50/25/12.5 payout scheme, why ECDSA, why only those opcodes in scripts, ...) that were set right from the start and agreed upon by everyone who ever used the system. Were those rules "central planning" too?
I tend to agree with Pieter.
First of all, the true nature of Bitcoin seems to be the rigid protocol as it helps the credibility among masses. Otherwise one day you remove block size limit, next day remove ECDSA, then change block frequency to 1 per minute, then print more coins. It actually sounds more appropriate to do such changes under a different implementation.
Then I can't help this: With such floating block limit isn't everyone afraid of chain splits? I can imagine a split occurring by a big block being accepted by 60% of the nodes and rejected by the rest.
How about tying the maximum block size to mining difficulty?
...
The difficulty also goes up with increasing hardware capabilities, I'd expect that the difficulty increase due to this factor will track the increase of technical capabilities of computers in general.
...
The difficulty also goes up with increasing hardware capabilities, I'd expect that the difficulty increase due to this factor will track the increase of technical capabilities of computers in general.
This sounds interesting.
Re: 2013-01-23 virtual-strategy-GoGreenSolar Provides Bitcoin Access to Solar Energy
I just tried placing an order, there is no bitcoin option at the checkout. Google wallet, PayPal, or credit cards.
Any follow-up on this? I was considering an order.
http://www.gogreensolar.com/pages/bitcoin-for-solar-energy
Regardless whether it was or wasn't Tom, the situation is Tom should step forward and show his credibility (or face the refunds).
If the chips are finished, is there please a chance to take a photo? No secrets revealing, no clock buffers or anything.
If the business has run into problems, it would be wise to speak out and ask friends, the community, or the customers for help.
Maybe the customers will rather accept the problems and clarity, hence they are the venture capitalists.
BTW any news from the new owners? Or they are not owners yet? Or they are not the right owners? How confusing.
If the chips are finished, is there please a chance to take a photo? No secrets revealing, no clock buffers or anything.
If the business has run into problems, it would be wise to speak out and ask friends, the community, or the customers for help.
Maybe the customers will rather accept the problems and clarity, hence they are the venture capitalists.
BTW any news from the new owners? Or they are not owners yet? Or they are not the right owners? How confusing.
My ideas about possible screens.
* Generate new address
receive "generate new address" command from USB
display "Generate address?" "OK/Cancel"
generate new and
display "Show priv key?" "OK/Skip"
display "Priv key" "" "OK/Cancel"
display "Address" "" "Store/Cancel"
store and
transmit to USB
* Sign transaction
receive "sign transaction" command and from USB
display "Sign transaction?" "OK/Cancel"
parse values , , , []
display "Send-to addr" "" "OK/Cancel"
display "Amount" "" "OK/Cancel"
display "Fee" "" "Sign/Cancel"
sign using stored private keys for [] into (what if some send-from addresses are not in the wallet?)
transmit to USB
* List addresses
receive "list addresses" command from USB
display "List addresses?" "List/Cancel"
loop through []
transmit to USB
display "Address" "" "Next/Cancel"
end loop
* Delete address
receive "delete address" command and from USB
display "Delete address?" "OK/Cancel"
display "Address" "" "Delete/Cancel"
delete and its from storage
Maybe there could be also a PIN security feature for the device. The PIN would be a hexadecimal number entered in a binary form.
Once the PIN is set, the device auto-locks when disconnected or after some period of inactivity, and then it needs to be unlocked next time.
* Set PIN
receive "set pin" command from USB
display "Set PIN?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Setting PIN" "" "Confirm/Cancel"
store
* Unlock device
receive any command from USB when the device is locked
display "Unlock device?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Unlocking device" "" "Confirm/Cancel"
verify
unlock device and continue
* Generate new address
receive "generate new address" command from USB
display "Generate address?" "OK/Cancel"
generate new and
display "Show priv key?" "OK/Skip"
display "Priv key" "" "OK/Cancel"
display "Address" "" "Store/Cancel"
store and
transmit to USB
* Sign transaction
receive "sign transaction" command and from USB
display "Sign transaction?" "OK/Cancel"
parse values , , , []
display "Send-to addr" "" "OK/Cancel"
display "Amount" "" "OK/Cancel"
display "Fee" "" "Sign/Cancel"
sign using stored private keys for [] into (what if some send-from addresses are not in the wallet?)
transmit to USB
* List addresses
receive "list addresses" command from USB
display "List addresses?" "List/Cancel"
loop through []
transmit to USB
display "Address" "" "Next/Cancel"
end loop
* Delete address
receive "delete address" command and from USB
display "Delete address?" "OK/Cancel"
display "Address" "" "Delete/Cancel"
delete and its from storage
Maybe there could be also a PIN security feature for the device. The PIN would be a hexadecimal number entered in a binary form.
Once the PIN is set, the device auto-locks when disconnected or after some period of inactivity, and then it needs to be unlocked next time.
* Set PIN
receive "set pin" command from USB
display "Set PIN?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Setting PIN" "" "Confirm/Cancel"
store
* Unlock device
receive any command from USB when the device is locked
display "Unlock device?" "OK/Cancel"
display "1111 0111 10*_ ___" "F 7 8 _" "0/1" (enter 16 binary digits)
display "Unlocking device" "" "Confirm/Cancel"
verify
unlock device and continue
How can I use a wallet with a name other than electrum.dat and on a custom location?
You can run electrum with a parameter:
electrum --wallet=/wallets/mywallet.dat
I thought it must have been talked about before, thanks.
The argument is that the IP just relays the blocks and doesn't mine them, and that it must be a well connected relay.
But the IP is not listed among "hub nodes", http://blockchain.info/hub-nodes.
The site relays blocks only during network hash-rate peaks, as I remember.
So they switch on their fast relay during network peaks and try to confuse everyone
The argument is that the IP just relays the blocks and doesn't mine them, and that it must be a well connected relay.
But the IP is not listed among "hub nodes", http://blockchain.info/hub-nodes.
The site relays blocks only during network hash-rate peaks, as I remember.
So they switch on their fast relay during network peaks and try to confuse everyone
IP relayed 7 blocks out of 11, hence http://blockchain.info/blocks/82.130.102.160
blocks 215021, 215022, 215026, 215027, 215028, 215030, 215031
Do they have this hashing power? Isn't it freaky?
blocks 215021, 215022, 215026, 215027, 215028, 215030, 215031
Do they have this hashing power? Isn't it freaky?