(1) When are transactions no longer relayed by a node? In other words, when are they baked into an account such that they no longer are relayed? What determines when a transaction is not relayed anymore? Like I said, transactions are collected into blocks in the same way as Bitcoin transactions, so nodes would stop relying transactions in the same way as they do with Bitcoin. To be honest I'm not exactly sure how a Bitcoin node decides to stop relaying transactions. It is pull based, so any node can request older transactions. So in this implementation, a node may request a transaction that does not exist in any node. So therefore, there is some criteria when to throw away transactions. What is that criteria? (2) When the account tree is created. Are accounts relayed through the network for other nodes to store and reconstruct? Yes obviously the accounts are relayed through the network for other nodes to reconstruct the account tree. The account tree will be created after the first genesis block is created. Nodes will reconstruct the account tree when they are synchronizing with the network. [/quote] Does an account have an identifier or hash that will distinguish it from other version of itself in the network? (3) Which version of an account should a node accept? Is there a block height embedded in the account? Is there a hash that relates the same account to a previous version of it? In order to determine which version of the account tree is the correct one, a node must first obtain the full proof chain and the mini-blockchain with the highest cumulative difficulty. The master hash of the account tree is contained in every block header so that when the node has reconstructed the account tree they can make sure it contains the right data. The block height can be calculated from the number of block headers in the proof chain and mini-blockchain so it doesn't necessarily need to be stored in the account tree, but it would probably add a bit of extra security to do so. [/quote] How is the account information requested from a node? Do I ask the node, "give me account for block height 13?" If the block height is already at 15, do I return an error? (4) I need to understand the interplay of when transactions are sent and when addresses are sent. I also need to understand what happens when a transaction is in conflict with an address and how to determine if there is a conflict. I'm not sure what you mean. I get the feeling you still aren't fully understanding the concept of how the mini-blockchain and account tree are supposed to work. What do you mean "when addresses are sent"? Do you mean when are portions of the account tree propagated across the network? Like I said, that should only happen when a node is synchronizing with the network. The mini-blockchain wiki has the answer to all of these questions, please read it properly. [/quote] So are you saying that, once a transaction is included in a block it is never accessible or propagated through the network? The problem is, the P2P network is never certain until a number of blocks whether a transaction is in the block chain or not. So you can't start transmitting account information until you have the requisite number of confirmations. I'll be honest, unless there is a specification of the network protocol, then this specification is incomplete. |
|
|
|
In Bitcoin, Blocks and Transactions are what are broadcast in the the network. It's the same thing here... what is so hard to understand about what I said. Miners will collect the transactions into blocks and then when a miner solves their block they will release it to the network. Then the other nodes will add that block onto their mini-blockchain just like they would for a normal blockchain. In Bitcoin that would be the end of it, and you'd need the entire blockchain to calculate the balance of any address because the blockchain has no concept of address balances, it's a continual ledger which keeps track of where coins are sent to work out the balances. However in the mini-blockchain design the balances are saved into the account tree, and when a new block is accepted onto the mini-blockchain the nodes will use the transactions contained in that block to recalculate the balances of the addresses in the account tree. A transaction will contain a simple command like "send X number of coins from address A to address B". So the nodes will simply carry out those commands by altering the balances in their account tree, if an account doesn't exist then it is added to the tree, and then when the changes have been made they will recalculate the hashes in the account tree. Ok. Bitcoin is a P2P network, so I have to understand what messages are sent. (1) When are transactions no longer relayed by a node? In other words, when are they baked into an account such that they no longer are relayed? What determines when a transaction is not relayed anymore? (2) When the account tree is created. Are accounts relayed through the network for other nodes to store and reconstruct? (3) Which version of an account should a node accept? Is there a block height embedded in the account? Is there a hash that relates the same account to a previous version of it? (4) I need to understand the interplay of when transactions are sent and when addresses are sent. I also need to understand what happens when a transaction is in conflict with an address and how to determine if there is a conflict. |
|
|
|
So one Account has multiple addresses? Are these Addresses broadcast to the network? Sorry I misunderstood your earlier question. Yes I suppose you could call the account tree an address tree because it holds information about all the non-empty addresses. The account tree is simply a hash tree where the data blocks represents individual accounts. The reason we call them "accounts" is because they hold more than just the address, each data block will also hold the balance of that address and some other information about the address. Each account will hold information about a single address only. All nodes will have a copy of the account tree just like the blockchain. The mini-blockchain works just like a normal blockchain and it holds transactions just like a normal blockchain, the only difference is that it gets trimmed after a certain period of time. When a new block is generated and propagated to all the nodes in the network, those nodes will use the transactions in that block to update their copy of the account tree and then they will recalculate the master hash of the account tree and make sure it matches the master hash specified in the block header, if it doesn't match then the block is considered invalid. I suggest that you read the mini-blockchain wiki properly, it explains everything in detail. Clearly there is something missing here. In Bitcoin, Blocks and Transactions are what are broadcast in the the network. What is broadcast here? I would think that transactions are broadcast. So they are collected in Blocks. So blocks contain transactions. Or.... not in this case... how are transactions consumed? I am missing something here. Also, I don't understand how you can update the global account when a peer doesn't see all the transactions. |
|
|
|
The account tree is a totally new concept, there is nothing like it in the bitcoin design. The account tree is basically just a database of all the non-empty addresses. It's structured as a merkle tree so that the network can easily keep track of changes and maintain the integrity of the data held in the database.
So one Account has multiple addresses? Are these Accounts broadcast to the network? How does an Address know that it is associated to an account? With Bitcoin, the only two object that are broadcast are Blocks and Transactions. Are you saying that in your system, there Proofs, Blocks, Accounts and Transactions that are broadcast? Are there transactions? |
|
|
|
so you try to calculate the hash only for the parts that changed? Correct. Since it's structured as a merkle tree you only need to work on specific branches of the tree when something changes, but changing just one account will change the master hash. When you talk about an Account tree... you mean an Address tree in Bitcoin terminology? |
|
|
|
my ixcoin wallet is telling me no addresses are valid, got a fix please?
what version is this? |
|
|
|
|
5000, OOO
1000, romawi
10000, garicup
10000, nomailing
20000, canth <--- exceeds limit
10000, chetalk
3000, kolbas
10000, teco051
10000, bitular
8000, indigon
4000, homerzhu
2000, nfigueir
5000, tobyliciously
10000, atomiclock
1000, hvezdasmrti
10000, smophf7
10000, ow48uh
10000, rioshock2
1000, fragout
10000, sottymax
4000, LeFiste
10000, soarlyzed
10000, snipedrunk
2000, Swisscoin
5000, dannac
10000, fibbonac1z
10000, vemdoctor9
5000, Siegtal81
5000 irrawaddybtc
10000 Franconomasky
2000 cntrlsquare
10000 Jaguar0625
5000 NapoBear
10000 tylenol3mit
6000 dlog
1000 toolatetoberich?
2465 eXme
10000 miramare
1000 langkeming
1000 steyast012
1100 alrose
7000 bitfromit
1000 icoinv
4000 lenco
1000 Msile
10000 ripplebtc
10000 cremstopper
10000 jajansen
2683 lonesoul
5000 zurra
5000 td services
10000 lda1000
7000 SyRenity
10000 wallacemckart
10000 Attack.of.the.Clones
3000 serogen
4000 atleticofa
7500 Kuttingco
7500 Kuttingcorners
10000 User705
1000 tk808
1000 virtualaddict
10000 Revelations86
2500 psybits
10000 aa417444103
1000 sydorFunk
2500 silanmil
9500 solracx
9500 Come-from-Beyond
10000 hunglejungle
5000 godt
10000 olano
1000 mingophoria
2000 yshuifejng
7500 mattmct
2000 Onkel S.
2000 Microove
1000 Maverick69
5000 kavin2468
10000 atriz
2000 tk808
10000 cc5alive
2500 Bourbon44
2500 extee
1000 rb2
2000 waytogo
2000 standards
5000 td services (added 5000)
1500 luckygenoug56
3000 bluedude
3000 xperiencia
1000 BitSugar
10000 grajson
10000 wizzardTim
1000 Abyss_X
10000 Gaman
3000 bitdraw
546,000 total <-- 54% of Limit
Limit is 1,000,000 NXT
Limit 10,000 NXT per User
Amounts under 1000 NXT not listed here but will be included
Appears to be around 100,000 NXT commitments per day. This will likely close in 7 days. So don't forget to make your reservation.
|
|
|
|
Just received a letter from bitmine.ch! By the end of the next week our production will start and I will have more information about the shipping date of your order.
Thank you for your understanding. No comments!  wait a minute, the end of the next week  !!!! this is 9th of February !!! this is a 2 diff. retargets.... and add to that the shipping time !! now if cointerra start shipping this week we are seriously doomed CoinTerra™ begins shipment of the TerraMiner™ IV – the world’s fastest Bitcoin miner January 28, 2014 http://cointerra.com/pr-cointerra-begins-shipment-terraminer-iv-worlds-fastest-bitcoin-miner/Damn!! |
|
|
|
Hi. I will reduce the voting deadline by 7 days however I believe it is important that we allow sufficient time for more ixcoin holders/supports than the 5 or 6 who voted already before a final decision is made. Unfortunately the voting site doesn't allow you to change your vote. https://tricider.com/en/multiBrainstorming/CNvkI believe the 3 options most suitable towards a re-brand are images 1; 12 and 23. 1 - Will lead towards a technological website layout. It won't be eye catching however it will look smart and sharp. It would be suitable if the target market was only gamers/IT enthusiasts. 12 - This is very retro, eye catching and would lead towards a very colourful website with strong red and yellow/gold themes. 23 - This is strong, simplistic and leads towards a clean minimalist website design. This image is symbolic and easily transferable to other website designs and promotional products so much so it looks like something from a clothing brand. I'm personally leaning towards 12 or 23. Please reply to this post with your preferred images. I am also in favour of 12 and 23. I think we can keep both for different purposes... 12 for "standard" websites and 23 for press releases and related because it's more professional like. 12 is too retro for my tastes. 1 and 23 for me. |
|
|
|
The account tree is made of accounts. Are these only the accounts that have changed during the block, or is it all the accounts for the entire block chain? The account tree holds all non-empty accounts that exist (that's why it's possible to have a mini-blockchain instead of a full blockchain). Interesting. Hmmmm.... so you try to calculate the hash only for the parts that changed? I guess this a merkle tree? |
|
|
|
Can you update the official website ixcoin.co please? Otherwise they will think I am a scammer.
done www.ixcoin.co |
|
|
|
|
Please leave your IXC address so we can pay bounty.
Thanks.
|
|
|
|
 For the religious inclined inscribe, in the outer circle. Ιησούς Χριστός Σωτήρας For the pragmatic, inscribe: Internet eXchange Coin or Internationalis Mutatio Nummus |
|
|
|
May we communicate the new Logo? Which one?
Any of the 3 should be fine. The red, yellow and gray one. Actually, different ones for different mediums, the gray one should be for black and white print. We need one for a paper wallet since the red and yellow ones don't print well. We need a version that prints well in color. |
|
|
|
In the article I linked yesterday comes out an issue about Bitcoin (and of course iXcoin): the growing dimension of the blockchain, now around 13 GB. Question: is this issue going to affect iXcoin too? Is there any way to make this blockchain slimmer, like allowing to the user to remove old transactions, in other words to choose between a synchronization with the full blockchain and a lighter one. Am I saying absurd things?
The iXcoin block chain is extremely slim, it takes less than an hour to download it entirely. iXcoin will keep in sync with the latest upgrades to Bitcoin, so one Bitcoin solves their problem, iXcoin will have a solution. Bitcoin also has what is called a SPV (Simple Payment Verification) client, this is something I would port to iXcoin in the future. In fact, for Bitcoin, their SPV client (MultiBit) is the approved client. |
|
|
|
Very nice, very professional. I also like the the 3rd one you did. |
|
|
|
Question: what have we now, one or two dev teams? Are they going to work together?
- Choice of name: done (?!?) still the same
- Logo: done (?!?)
- Website update:?
- Windows wallet 0.8.6
- Press releases
- Colored coin / smart money
- etc..
Who is gonna do what? Have we to wait 19 days to end the survey before action?
Is there a shared plan of development? If not, is it possible to unify the efforts to achieve greater results with one single development plan?
I have not talked to Luke yet, but I gather that he is most interested in developing the website and marketing strategy. I would like to just focus on technical aspects... i.e. colored coins. |
|
|
|
Wow, interesting. IXC means Jesus Christ? Then what Vlad was saying about XIC being the devil holds some water since the devil likes to do everything backwards. Wow, the symbolism just keeps on coming. You folks are into too much conspiracy theories. IXC is just a coin created by some anonymous dude using an anagram of "Satoshi Nakamoto" IX itself is used a monogram for Jesus Christ see: http://en.wikipedia.org/wiki/IX_monogramIt is just a coincidence that I X C is greek (Iesus Christus Soter, Jesus Christ Savior). Google translate: http://translate.google.com/#en/el/Jesus%20Christ%20SaviorSo it is I X (Sigma) . However, http://en.wikipedia.org/wiki/Sigma During the Hellenistic period (4th and 3rd centuries BC), the epigraphic form of Σ was simplified into a C-like shape. But all of this is just coincidence, IXC means Internet eXchange Coin. So move on folks... there is nothing to see here! |
|
|
|
|
Show Posts
