There are solutions - like what Ethereum is trying by using a block tree, rather than a simple chain - but someone else can probably explain that better.
I don't think the blocktree in Ethereum's configuration really addresses this, as the block times are still one minute (or at least, were when I last talk to Vitalik). Aside from that, extremely fast blocktree implementations (as in the GHOST paper) still requires tx to traverse the network among different nodes and will probably hit bandwidth problems comparable to Bitcoin, if not worse because very large numbers of blocks containing the same tx will be hitting the network at nearly the same time any given second. It's more a solution to the problem of insecurity introduced by large blocks on a slow network. |
|
|
|
|
^^ yeah sorry, I realized stating key pairs could be confusing after posting. I meant key pairs owned by the exchange with corresponding outputs they could spend at some pubkey hash (address).
And yeah, that's another way of doing it that could allow for more than one instance of transfers per block -- either way should work, so exchanges should still be able to function okay.
|
|
|
|
|
Looking forward to the obelisk white paper!
|
|
|
|
The only super broken thing (as far as I can tell) is that the designers for some reason decided to use txid for the spending of unconfirmed outputs. For exchanges this isn't really a problem, a possible solution is posted in the other thread (per block settlement tx) and look for immutable things in txs that are included in subsequent blocks. The ECDSA signatures generated will always be random because of the specifications, but pubkeys and their hashes (addresses) and the values of inputs/outputs are always immutable for any given tx. As far as I can tell, generating immutable txid actually isn't that hard -- there are a bunch of immutable things in any transaction you can choose to hash instead of mutable things like ECDSA signatures. This isn't a problem for most of the large exchangers anyway, as they're not using bitcoind in the first place as it's poorly scalable and recognized the problem that malleability posed long before. |
|
|
|
Exchange can still send bitcoin at any time, just don't try to spend unconfirmed change. Anyway, it is always a good idea to pay multiple clients in one transaction
Yeah, but the issue (I would guess?) is that exchanges were paying one client, then using the unconfirmed txid with their unspent output to pay the next client, and so on and so on... if you have a lot of money paying one client (+ change to yourself) and then are waiting one at a time for a block to confirm your last client's tx is a bad idea, because you'll lock up lots of your coins and slow down your withdrawals to a crawl (one client per 10 minutes, ouch!). You also don't want to split your coins into tons of different key pairs because then you're accumulating expensive tx fees. So ideally you should be doing per block settlements (which most exchanges like btc-e already were, I think). |
|
|
|
The malleability attack becomes a DOS attack. We need a quick fix. Before there is a better solution, the bitcoind should not report unconfirmed transactions. Account balance should be solely based on confirmed transactions. Before malleability is fixed (if ever), unconfirmed outputs should not be spent.
How does it become a DoS attack? Care to explain? The clients track unspent outputs before forwarding tx (or mining it). How does malleability cause a problem? I don't see any issue (non-gox) unless I missed something. Why the quick fix? It does not seem urgent. Lets do it properly and thoughtfully. Most current wallets will attempt to spend unconfirmed change outputs. If the tx id is mutated and the mutated versions ends up in a block then the spent change output becomes permanently invalid. For a site like an exchange with a large amount of withdraws (spends) it is very likely they will spend using unconfirmed change outputs and thus end up with broken outgoing payments. More info: https://bitcointalk.org/index.php?topic=460944.0The "quick fix" is to have clients deal with the possibility of tx being mutated before confirmation in a more consistent and expected way. The improvement to immutable tx ids is a long complex process which will require extensive testing. It won't be quick. I didn't realize that spending unspent newly generated outputs used the txid. That's actually a potentially serious design flaw, as the core dev knew these were mutable. To fix this at the exchange level, you can just only send outputs to clients after a new block is received once and only once... just make huge tx with all of the inputs you need to use to pay your clients and all of the outputs to all of your clients withdrawing. Then use my proposed txid system. |
|
|
|
|
This is what I would do; ignore txid itself, but instead use the output from 4.):
1.) For any incoming transaction generate a list of inputs and values from inputs, concatenate into a string; sort addresses alphanumerically before doing so
2.) Generate output hashes and values and concatenate into above string; sort addresses alphanumerically before doing so
3.) Concatenate the pubkeys from the inputs that are regenerated from the signatures (NOT the signatures themselves) into the above string; sort pubkeys alphanumerically before doing so
4.) Hash this big string and use it as the txid
Even if someone regenerates signatures at random for any tx, the above will never change. Any duplicate tx that are mutated will come up the same using the above scheme.
Probably even more simply you can just skip step 1.) and put the values of the inputs after their respective pubkeys and then stick it into a string along with the outputs
This can be implemented quickly, probably in 30 min - 1 h. Exchanges verifying that a tx went through need only look for the above alternative txid hash in the next block and then can verify its incorporation into the blockchain.
I'm tired and going to bed so I hope this is coherent, but verifying blockchain incorporation using this scheme should enable protection from tx malleability
Comments welcome
|
|
|
|
|
Someone is running malicious code that receives tx and then retransmits them mutated. Only one gets incorporated into the block chain eventually. Kind of a nuisance, i guess they're trying to mess up every exchange right now that operates on txids. Bitpay, coinbase, coinvoice all use custom daemons anyway so not a huge issue.
|
|
|
|
An update is going out now via BM -- sorry it's been quiet, the update elaborates.
What is the BM address? Just PM me one to reach you at |
|
|
|
An update is going out now via BM -- sorry it's been quiet, the update elaborates.
Do I have to keep Bitmessage open 24/7 to receive messages or are they pushed when i go online? They're circulated around the network for 2 days, and then I have to resend again (but I think that process is automatic) |
|
|
|
Does all that mean, the dream of 100% uncompromisable P2P transfer is over? Does it mean an additional check by a quasi central authority is needed to augment security? I would appreciate an answer in layman terms.
No. Everything is just the same Let say bitcoin transaction is like a banknote. You can write something on a banknote but the note itself is still valid. When gox sending a banknote to its customer, they take a picture of the note, and use the picture of the note as an evidence of delivery. Some customer, however, write something on the note when they get it from gox, and claim they have not received the note. Since the note looks different from the photo, gox can't recognize it and wrongly believes that the note is not delivered, and send another note to the customer (so the customer gets double paid by exploiting the gox's bug). Since gox believe the original said note is not spent, they try to send it to a different customer. Of course this won't work and led to all those bitcoin withdraw problem we have seen. So gox now proposes to use a different method to track the banknote. Instead of taking a photo, they propose to use the unique serial number on every note for tracking propose. Bitcoin is still the bitcoin we know yesterday Following this analogy how do other exchanges tackle this problem? Understand the protocol before you write software for it... |
|
|
|
|
An update is going out now via BM -- sorry it's been quiet, the update elaborates.
|
|
|
|
ok. however i got your point.
the real thing is:
this coin will be asic resistant, just because it is stated in the title.
i mean, no real asic developer would risk that amount of money to strike against a coin that has clearly declared war against them.
they have a long development and cannot imagine what countermeasures would be taken from the developers in case.
just the idea of a fork to change algorithm is enough to make that investment too risky.
Well, yes, you can always just keep changing the hash function itself every 3 months or something so long as your community agrees with it. |
|
|
|
It's part of the reason I'm dropping scrypt from the next MC2 whitepaper, most likely. so are you here to advertise your own coin? No, especially when all of that is just theoretical at this point... |
|
|
|
Thank you for the direct response before. We have pretty much reached my level of understanding in this matter until I educate myself better.
Anyways, after looking at the code wouldn't having those extra variables be easier to implement in an FPGA? I think you can easily do so with FPGA; see https://github.com/kramble/FPGA-Litecoin-MinerThe author already implements the LOOKUP_GAP=2 version of the core algo and states it's faster among multiple cores This doesn't mean it will be fast or energy efficient on the FPGA, though Also, is the mixing function designed to accept a specific amount of data using one N value, or would is just take twice as long as previous Nfactor + 1?
I'm saying this because increasing the size of y by one will double the amount of memory used, and then send it off to be mixed.
In the very least, I could see the mixing speed decrease by half with every increase in N value i guess.
I'm not sure I totally understand your question, but I think y in this implementation is logarithmic for N (y=log(N)). Hence y+1 = ~doubling of mixing |
|
|
|
Can you upload a pic of the fan setup ?
thx
If you promise not to laugh XD Just using cable ties to attach the fans to the case. I used an extra molex adapter from a corsair HX psu, as they use the same cables  Not the prettiest in the world, but the vreg heatsinks are at about 45C now |
|
|
|
So I figured I'd have more overclocking leeway than 570. Any suggestions? Try get your temp up to 70+ and test again, Phil said 70-80°C is the sweet spot for the silicone Yeah, but at 550 clock my temps are the same (65-67) and I have no problems at all. The higher your clock rate, the more important it is for the silicon to be in it's "happy state". Just get the temps up to ~80 and try overclock and you will know. I'm just repeating what Phil said like 15 pages back. I find that the temperature of the core is less important than the surrounding regulators; I seem to get more stability actively cooling those with 120mm fans. |
|
|
|
Thanks tacotime for starting this. I would love to see more opinions.
If we got an ASIC designed for N-factor x and the N-factor changes to y. Would the N-factor x ASIC still be efficent on N-facot y?
Yes. Adjusting N-factor will not help very much so long as the ASIC already has N-factor set up to be dynamic, which should not be expensive to implement. Making it larger is ideal, but the problem is that GPUs themselves use the same trick ASICs do to calculate hashes for larger N-factors in parallel, so it's not really a huge help. It's part of the reason I'm dropping scrypt from the next MC2 whitepaper, most likely. |
|
|
|
I think you need to break this down for me in-detail. I don't understand chip design. However my brain is computing what you are saying as "solder on some doo-hickies and make go faster". I was under the understanding that aspects of the hash equation are being stored (floating?) in active memory waiting to be re-addressed or re-utilized or whatever is going on. Less memory, less-computational storage, less speed/fewer threads/streams to get the hash IN and OUT complete. Therefore no amount of additional circuitry that regenerates anything is going to help you. Its simply down to transistor/die count and the amount of fast-access memory close by to be the sandbox. The bigger the sandbox the better.
If there was this simple short-cut to undermine N-factor, N-factor would be useless. I thought that using lookup-Gap to hash in less memory would require more hash cycles, if that is what 'this circuitry' is doing.
scrypt is based mostly around a tradeoff for memory usage. That is, if you use less memory to generate the hash, more integer operations are required because you have to redo the salsa20/8 (or whatever stream cipher) loops for a specific value that you didn't bother to store in your scratchpad. scrypt functions such that as memory decreases logarithmically, the number of operations required increases exponentially. I guess the ELI5 would be: you can run scrypt in log(x) many clock cycles with memory x, or you can run scrypt in x many clock cycles with memory log(x). For ASICs, ideally you aren't using massive quantities of SRAM, so you just make a bunch more scrypt processors with smaller amounts of SRAM than would be required in the original implementation of the paper, that are then ran in parallel. FPGA still struggles with this implementation to provide performance in any cost reasonable sense (it's still more efficient), but then when you push it to an ASIC, it functions fairly efficiently (it's been suspected that the GridSeed chips are simply using a direct synthesis of one of the fast published FPGA code available on GitHub). |
|
|
|
Exactly what are "just a few circuits"? Relatively technical so don't hold back, you seem extremely familiar w/ vlsi design and it would be great to elaborate. And why would these values be calculated on the fly, rather than flipping a hard switch to set your iterations?
It's the implementation of the function reported below in cl code. All you have to do is make N, LOOKUP_GAP, and CONCURRENT_THREADS dynamic. void scrypt_core(uint4 X[8], __global uint4*restrict lookup)
{
shittify(X);
const uint zSIZE = 8;
const uint ySIZE = (N/LOOKUP_GAP+(N%LOOKUP_GAP>0));
const uint xSIZE = CONCURRENT_THREADS;
uint x = get_global_id(0)%xSIZE;
for(uint y=0; y<N/LOOKUP_GAP; ++y)
{
#pragma unroll
for(uint z=0; z<zSIZE; ++z)
lookup[CO] = X[z];
for(uint i=0; i<LOOKUP_GAP; ++i)
salsa(X);
}
#if (LOOKUP_GAP != 1) && (LOOKUP_GAP != 2) && (LOOKUP_GAP != 4) && (LOOKUP_GAP != 8)
{
uint y = (N/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z<zSIZE; ++z)
lookup[CO] = X[z];
for(uint i=0; i<N%LOOKUP_GAP; ++i)
salsa(X);
}
#endif
for (uint i=0; i<N; ++i)
{
uint4 V[8];
uint j = X[7].x & K[85];
uint y = (j/LOOKUP_GAP);
#pragma unroll
for(uint z=0; z<zSIZE; ++z)
V[z] = lookup[CO];
#if (LOOKUP_GAP == 1)
#elif (LOOKUP_GAP == 2)
if (j&1)
salsa(V);
#else
uint val = j%LOOKUP_GAP;
for (uint z=0; z<val; ++z)
salsa(V);
#endif
#pragma unroll
for(uint z=0; z<zSIZE; ++z)
X[z] ^= V[z];
salsa(X);
}
unshittify(X);
} It's not a leap of faith to see this hard coded into an ASIC, though I'm not overly familiar with FPGA/ASIC design, Verilog synthesis, etc. (talk to Peter Todd about that, ideally) Why I say "on-the-fly" I'm referring to the way the TMTO algorithms usually work... You write every nth value to the table (scratchpad) where n is the LOOKUP_GAP, and execute it on c many CONCURRENT_THREADS. When you need a value that hasn't been stored in the partially generated scratchpad, you generate it as necessary. |
|
|
|
|
Show Posts
