|
bji, you appear neither to understand how transactions work, nor how they propagate across the network and you make dogmatic assertions of things that just aren't true.
Your "screwing a restaurant" scenario doesn't work as the transaction paying the restaurant owner has a significant lead in propagating across the network. Your "tricking a retailer" strategem doesn't work as the retailer would see the double-spend transaction to yourself and refuse to part with the goods. Your "5 minutes in advance" scenario doesn't work as the retailers "listener" is "tuned" to all transactions and hence rejects your transaction.
Contrary to your assertions, accepting small transactions with no confirmations can be made fairly safe.
I invite you to prove me wrong by implementing one of your attacks in a reasonable setting.
ByteCoin
|
|
|
|
These business would know that announcement of their try would lead to an increase in the future difficulty level. Therefore they would want to place bets on future difficulty increases before announcing their entry.
Existing business would take the other side of these bet to insure themselves against loss.
I don't understand what motivation the existing businesses would have to take the other side of the bet. Could you please explain? The value of bitcoin is inversely proportional to its velocity. If merchants are constantly exchanging BTC for USD after every transaction, the velocity will be high and BTC value will be low.
You need to define what sort of transactions contribute to velocity. For instance, if I take money out of my safe and put it on the table and then put it back in the safe, even if I do this millions of times a second I'm not decreasing its value. I think you'll find that currency conversions also don't contribute. Could you also please explain what you're trying to achieve with contingent blocks? It looks like an option based on difficulty. What does it enable? ByteCoin |
|
|
|
...
For example, miners would have the option of mining instantly maturing bitcoins or bitcoins maturing on Jan 1st of 2012, 2013, 2014, 2015, 2016. (one to five year maturity)
Average difficulty for all maturities would be pegged to hold the total number of all types of coins constant according to Satoshi's schedule.
...
So, given that the client instantly converts bitcoin bonds on maturity into bitcoins and given that the number of bitcoins in the economy meets a fairly strict schedule, in the run up to the maturity of one set of bonds the bitcoin client would have to know how many bonds were going to mature and adjust the difficulty of the normal block generation so that after they mature, the right number of bitcoins is in circulation. This would probably mess up the block generation rate in the time before maturity and so prevent this implementation of bonds. Block generation provides timely transaction confirmation and anything which harms this cannot be tolerated. ByteCoin |
|
|
|
...
[It] takes quite a bit longer than 6 seconds for a solved block to propagate around the network to all miners.
...
The miners should take care to relay their solved blocks directly to the other miners. It's in all the miners best interests to do so. This is true of the current system too. Propagation is so slow in the current network because each node verifies all the transactions and blocks before relaying them. In reality only the miners really need to verify anything. The nodes just need to take adequate steps to ensure they're not either being attacked or being used to attack someone else. There's no evidence to back up the assertion that fragmentation and reorganizations would be inevitable. How would it be possible to create a new coin, tied to bitcoin (but at a fraction of the value) that is updated more regularly.
One would have to change or augment the existing bitcoin system with the new coin scheme. The network would agree to create bitcoins out of thin air in response to the new coin scheme destroying coins and vice versa in a similar fashion to creating coins when mining blocks. Hashing power would be split between both systems and the overall behaviour would be complex. A better, simpler solution would be a replacement scheme similar to bitcoin that would facilitate a higher block generation rate. ByteCoin |
|
|
|
...
gmaxwell from IRC thinks it can be done without multiple signatures
...
Can that equation be refactored so that Device 1 can compute part of the signature, send its partial result to Device 2, and have Device 2 complete the signature (without Device 2 being able to figure out 1's part of the private key?)?
I presume it's also not acceptable for device 1 to be able to figure out device 2's part of the private key after viewing the completed signature. I've looked into this already for a very similar application and initially I was hopeful too. k is a random number provided by the first signer with the intention of preventing the recovery of the private key d by simple algebra. The second signer would need to incorporate their own random number into the "k" portion of the equation in order to prevent the first signer from deducing their d B by analogous manipulation. However there doesn't seem to be a way of making a signature that behaves like ECDSA without revealing secret information. Now it's Hal's chance to shine by showing how it's done! You can probably create a multiparty signature but it would have to be verified by a different algorithm to the standard ECDSA and hence would be entering worryingly novel crypto territory. The benefit over multiparty signatures implemented in the script would be small. I don't know much about secure multiparty computation but there may be a solution down that avenue but it would be a bit like using a sledgehammer to crack a nut. ByteCoin |
|
|
|
Bump. I just realize a reason this is immensely useful (besides Eligius): no longer do transactions require unique destination addresses. A merchant can publish a single address/email pair for all purchases, and clients can send the purchase information via email, signed by the sending address.
If you want to use a single address for all purchases and still be able to tell who paid you and also pass secure messages then you need the method described in http://forum.bitcoin.org/index.php?topic=5965.msg87757#msg87757This can be implemented with the current network and client environment. ByteCoin |
|
|
|
I think the transaction cancelling/superseding issue is one of the most technically complex outstanding issue needing to be addressed. Bitcoin can cancel one input per day until one of the cancellations goes through.
Are you saying that this is something that already happens in the code or is this something you are proposing to be implemented to solve the problem in future? If it is in the code, could you please indicate where? Could you please also be a little bit more explicit as to how the input cancelling would solve the problem? And why only cancel one per day if more are eligible for cancellation? Thanks, ByteCoin |
|
|
|
Actually, the addresses and keys are ECSDA IIRC.
The addresses are essentially the base58 representation of the result of the RIPEMD160 hash of the SHA256 hash of the public key point. The derivation of the address from the public key has nothing to do with ECDSA. Your linked article and recent response to my observations make it clear that you are not fully familiar with the cryptography behind Bitcoin. You may wish to learn more so that your opinion can be taken seriously. ByteCoin |
|
|
|
|
Bitcoin would not survive a sufficiently serious break of sha256 (such as the ability to quickly find first pre-images) as it would become feasible to generate successive blocks which hash to zero.
Your article also only considers the use of sha256 as part of the proof of work. The hashes are also used as a unique identifier for transactions and in the derivation of the address from the public key.
ByteCoin
|
|
|
|
Thanks theymos! That makes sense. How is a newbie expected to make useful posts?
Questions can be useful if the newbie has taken appropriate care to be clear, concise and neither the question nor the answers have appeared in the forum in any obvious places before. Just to raise the usefulness of this post: I'd like to point out that newbies are posting messages essentially void of any useful content in order to escape newbiedom. This probably decreases the usefulness of the board for the newbies who actually play by the rules making them want to escape etc... I think the current newbie confinement strategy is failing and an alternative needs to be found. How about "Newbies must request whitelisting and their posts are reviewed for usefulness before acceptance"? Similarly, non-newbies should be demoted to newbie if their posts show insufficient usefulness upon review. ByteCoin |
|
|
|
I've never thought that the number of posts was a useful metric for assigning seniority to members as it encourages people to post even when they don't really have anything to say. However, that's how it's implemented now and we might as well make sure it's working. It's not. Let's pick on Forp. I'm picking on him as he's actually OK and therefore will (probably) not suffer from my drawing attention to him If we list his posts, at the time of this message he has six but his profile says he's posted 10 which allows him to escape the newbie-zone. Perhaps people should need to apply for "promotion" and their posts be reviewed for usefulness. I'm confident Forp would pass but others.... not so sure! ByteCoin |
|
|
|
According to the spec, varint should do:
<= 0xffff 3 0xfd + uint16_t
So what it seems to do is only setting the total value in the next two bytes without subtracting 253 of it.
The mainstream client is the only spec that matters at the moment. From serialize.h void WriteCompactSize(Stream& os, uint64 nSize)
{
if (nSize < 253)
{
unsigned char chSize = nSize;
WRITEDATA(os, chSize);
}
else if (nSize <= USHRT_MAX)
{
unsigned char chSize = 253;
unsigned short xSize = nSize;
WRITEDATA(os, chSize);
WRITEDATA(os, xSize);
}
etc...
So yes, small numbers have multiple representations. ByteCoin |
|
|
|
|
I think it's fair to say that this decision was fairly arbitrary. Possibly Satoshi meant to revisit the design to eliminate other areas where more space is wasted but was already getting fed up with the project and chose to release it before he ran out of steam.
ByteCoin
|
|
|
|
Shopping could not be completed faster. If blocks were found twice as fast, then it would take 12 blocks for a transaction to confirm, as each block would be worth half as much.
I think if you worked the maths through carefully 12 blocks of half the difficulty would actually be somewhat more secure than 6 blocks at the current difficulty. Similarly I think that the current scheme is more secure than 3 blocks at twice the difficulty or one block at six times the difficulty. I think it works a little bit the same way that compound interest using the exponential function is more lucrative than effectively the same rate of simple interest. So 100% simple interest on x after 1 year gives you 2x. 50% interest half-yearly gives 2.25x. 25% quarterly gives 2.44x and the limit is e = 2.7183ish I don't have time to justify this at the moment. Hopefully I will either revisit this topic or someone else will pick up the torch. For the practical purposes above, the difference will be small. ByteCoin |
|
|
|
You can check your solution against these exact answers: | 0 | _ | 738035/120932352 | | 1 | _ | 586435/10077696 | | 2 | _ | 4301435/20155392 | | 3 | _ | 33057475/90699264 | | 4 | _ | 33616325/120932352 | | 5 | _ | 1145495/15116544 | | 6 | _ | 737353/181398528 |
I don't think it's a particularly easy problem. An exact formula for the probability of no matches is 6^-12 * Sum_{k=1..6}(6-k)^6 * C(6,k) * Sum_{j=0..k} (-1)^(k-j) * C(k,j) * j^n where C(a,b)=a!/(b!*(a-b)!) but this is a simpler case than the other numbers of matches. Possibly proper mathematicians have more powerful tools to bring to bear on such problems. Explaining even this simple formula would take quite a lot of work but if you're willing to crack open a maths book then "Stirling numbers of the second kind" would be a good place to start. ByteCoin |
|
|
|
thank you bytecoin that is very close to the random data. to pay the bounty though, i must see how you arrived at your final numbers. did you use a formula or did you write out numbers on a page 46000 times?  Essentially the latter. Do I get the money now? doing that would assume 'hard-coding' of the number of product variations (6), which i'd rather avoid.
Is this a real world problem you're trying to solve? What is the range of the "product variations" and how much do you care (in BTC) about an exact answer? ByteCoin |
|
|
|
matches count(matches) (count(matches)/5831*100)
0 37 0.6345
1 359 6.1567
2 1222 20.9570
3 2099 35.9973
4 1676 28.7429
5 417 7.1514
6 21 0.3601
I have solved the problem but the method would be tedious by hand. If it's an academic problem then there's a better way than mine. No pairs 1 pair 2 pairs 3 pairs 4 pairs 5 pairs 6 pairs 0.61% 5.82% 21.34% 36.45% 27.80% 7.58% 0.41% kjj's method cannot succeed. If one party chooses 123456 then we must have at least one match whereas if one party chooses 111111 then there's about 1/3 chance of no matches. This thread should probably be moved to Bitcoin Forum > Economy > Marketplace > Buying ByteCoin |
|
|
|
|
Show Posts
